Trying again: select() should be a cancellation point
s_sourceforge at nedprod.com
Sat Jan 29 07:14:40 PST 2005
On 29 Jan 2005 at 14:31, Niall Douglas wrote:
> As no one replied last time, here's this email again.
> I've found that I cannot work around select() not being a
> cancellation point on FreeBSD in my code - I had to #ifdef
> __FreeBSD__ in a hack which manually calls pthread_testcancel() every
> second. This is *nasty*!
> If there's any alternative, I'd very much like to hear it. Preferably
> I'd like to see select() made a cancellation point or a new form of
> select() eg; select_tc() added.
Isn't it typical that five minutes after you send an email you
realise you were wrong? :(
It seems that select() indeed IS a cancellation point. What was
happening was that my code does the following:
1. Thread waits on non-blocking read pipe using select()
2. Thread gets cancelled. This invokes thread cancellation handler.
3. Thread cancellation handler sends a "I am disconnecting" message
to write pipe. Note that this is a blocking pipe not the same as the
read pipe. The message is tiny, around 20 bytes.
Now on all systems, the write pipe is always kept fully empty and
because they have a 4Kb buffer, 20 bytes should NEVER stall. But on
FreeBSD it does stall where it does not on Linux nor WinNT. And
that's why I had thought select() was not a cancellation point as the
thread seemed to never die.
Note that sockets work fine here, as do files ie; you CAN write data
to these during a thread cancellation handler. Unfortunately it seems
the same is not true for pipes.
So what's going on then? Thoughts? You guys will probably want a
short example ...
> > According to:
> > http://lists.freebsd.org/pipermail/freebsd-threads/2004-
> > October/002572.html
> > ... it is. But v5.3 FreeBSD doesn't cancel during select(), nor
> > during recv().
> > OTOH I have other documentation which suggests that neither select()
> > nor recv() are cancellation points.
> > Oh and on Linux, both are cancellation points. In my mind it's
> > probably more useful if they are cancellation points as you can
> > always disable cancellation around them if necessary whereas the
> > opposite is not true.
> > Cheers,
> > Niall
> freebsd-threads at freebsd.org mailing list
> To unsubscribe, send any mail to
> "freebsd-threads-unsubscribe at freebsd.org"
More information about the freebsd-threads