Re: XSH/XRAT conflict over cancellation points

[Dave Butenhof <yyyyyyyyyyyyyy@xxxxxx>]

Schwarz Konrad wrote:

> > > int i;
> > > int fd = open ("/dev/null", O_RDONLY);
> > > char b [256];
> > >
> > > pthread_cleanup_push (my_handler, &i);
> > > pthread_cancel (pthread_self());
> > > i = 0;
> > > read (fd, b, sizeof b);
> > > i = 1;
> > > pthread_testcancel();
> > (Actually, it may see neither, because my_handler is a 
> > separate routine 
> > that's probably invoked via something like an exception handler or 
> > longjmp, and 'i' is a local variable that's not even volatile. ;-) )
> >    
> It doesn't say that in the standard!  At least, I can't find it on
> http://www.opengroup.org/onlinepubs/009695399/functions/pthread_cleanup_pop.
> html nor in
> http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html.
> Should that be filed as a defect?
>  
Hmm. Actually, I was thinking in terms of setjmp/longjmp or a C "inline" 
exception handler extension, with "out of line" code accessing the local 
'i' variable. In fact, after thinking about it more I'm not really sure 
whether either could reasonably foul up access in this code, because 
you're "publishing" the address of 'i' via the pthread_cleanup_push() 
token (even if it's not a call the value must be held somewhere), and 
both read() and pthread_testcancel() are external calls. This may 
actually be perfectly safe.

And to think I nearly deleted that wry little side comment of my reply, 
on which this digression is based, lest it detract from the real answer. 
Sigh. ;-)

--
/--------------------[ yyyyyyyyyyyyyy@xxxxxx ]--------------------\
| Hewlett-Packard Company       Tru64 UNIX & VMS Thread Architect |
|     My book: http://www.awl.com/cseng/titles/0-201-63392-2/     |
\----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/