Re: [Chicken-users] Race condition in scheduler.scm

[F. Wittenberger]

Am Sonntag, den 17.08.2008, 08:54 +0900 schrieb Ivan Raikov:
>   You should probably email Felix directly about that. I am not
> familiar with the threads library at all, so I am not qualified to
> evaluate this patch, and I don't know if many other Chicken users have
> had your level of experience with threads. At the moment, you might be
> the most experienced user of that library.

It already looks somewhat like that.  :-(

Am Sonntag, den 17.08.2008, 03:47 -0700 schrieb Elf:
> On Sun, 17 Aug 2008, Jörg F. Wittenberger wrote:
> 
> > Hi all,
> >
> > in this message
> > http://lists.gnu.org/archive/html/chicken-users/2008-08/msg00094.html
> > I posted a patch to scheduler.scm, which fixes a race condition wrt. bad
> > file descriptors in the waiting queue.
> > (Attached is a slightly brushed up version.)
> >
> > I have not seen any replies to this message (which is sort of strange on
> > this list).  Did anyone consider to roll it in?  If not, why?  Anything
> > bad about it?
> >
> > The race originally arose in a somewhat strange setup, which might not
> > be even repeatable for everyone, since it involved accidentally changing
> > the scheduling sequence (using more or fewer exception handlers), which
> > may have different results on different machines.
> >
> > But the issue as such is easy to recreate, if you make a thread wait
> > asynchronously on any file descriptor and close that fd from a second
> > thread.  (Something, which may or may not be intentional, but easy to
> > do.)
> >
> 
> i'm not understanding why this would cause a 'race condition', nor why your 
> patch is necessary.  the lines which you deleted from the scheduler (the -1
> check and forced-primordial) accomplish the same thing without raising an
> exception or causing modifications to the signal/condition/exception handler
> in unsafe ways.

Originally it came up as a race condition.  See my above referenced
message I.  Add/delete an exception handler from that code and - at
least on my machine - run into fake thread-join-timeout exceptions
endlessly.

And truly it is a race condition, since - depending on order of
scheduling - threads may or may not handle the case before the scheduler
switches to the primordial, possibly causing the harm.

Not, it's not true that forcing the primordial (and which is in some
unknown state at that time) will do the same.  The patch checks the
##sys#fd-list, removes bad fd's and retries.  Other -1 from select(2)
are still propagated to the primordial.  This should be understood as a
temporary bug compatibility since it's probably not much better, though
I haven#t been able to create a test case for those.

The patch I attached last time is actually broken (a typo) wrt.
signalling threads waiting for input.  Now, since I ran into that one
too, find a fixed patch attached.

Felix, could you please review the patch and integrate the fix.

Thanks a lot

/Jörg

ebadf.patch
Description: Text Data