Re: EventLoop.isCurrentThread() race condition

[Kris Van Hees <kris dot van dot hees at oracle dot com>]

On Fri, Jun 22, 2007 at 07:54:07PM -0400, Andrew Cagney wrote:
> Kris Van Hees wrote:
> >Take frysk.proc.ptrace.TestByteBuffer.
> >Comment out all tests up until the definition of the AsyncModify private 
> >class.
> >(I.e. comment out from the beginning of the verifySlice() method up to
> >but not including the declaration of the AsyncModify private class.)
> >Run the test a few times.
> >  
> 
> or ./TestRunner -r 1000 frysk.proc.ptrace.TestByteBuffer (although I 
> didn't see it fail).
> 
> Anyway, yes there is a race with the secondary thread getting to the 
> event-loop before the main thread; I've fixed that test.  Thanks!

I see that the way you "fixed" the test is functionally identical to the
"hack" I use in TestMemorySpaceByteBuffer to work around this EventLoop
problem.  I hope this hack is not meant to be the final solution to this
race condition?  This really should be resolved in EventLoop, rather than
introducing a hack to make this work, and potentially getting stuck with
this problem popping up in other existing and future code.  Depending on
side effects in what appears to be a basic query method is dangerous (as
we can see from the issue with TestByteBuffer).

By the way, the comment to run() in EventLoop is yet to be updated to
reflect the correct behaviour?

	Cheers,
	Kris