This is the mail archive of the frysk@sourceware.org mailing list for the frysk project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: EventLoop.isCurrentThread() race condition


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.

On Fri, Jun 22, 2007 at 03:36:08PM -0400, Andrew Cagney wrote:
> Kris Van Hees wrote:
> >On Fri, Jun 22, 2007 at 01:14:06PM -0400, Andrew Cagney wrote:
> >  
> >>Kris Van Hees wrote:
> >>    
> >>>Some tests in frysk-core
> >>>are actually using runPending or runPolling in a multi-threaded context
> >>>      
> >>Can you be more specific here, a thread and perhaps with a sequence
> >>diagram?  .runPending and .runPolling should be robust in a
> >>multi-threaded context provided they are being called from the main 
> >>thread.
> >>
> >>    
> 
> There's a typo by me in the above - more specific as in the test[s] - 
> i.e., which specific test is causing this problem?  This will give me 
> some context so that I can understand the events that that lead to you 
> identifying this issue.
> 
> It sounds like the underlying problem is a misplaced or missing call to 
> .runPending() or .start; but with no context, I can't tell.  If that 
> logic is correctly detecting that the event-loop thread switched, then 
> that isn't a bug.
> 
> >I assumed that would be the case, which means that the comment block
> >preceding the run() method in EventLoop is incorrect and definitely
> >should be updated.
> >
> >  
> 
> Yes.
> 
> >I quote:
> >    /**
> >     * Run the event-loop.
> >     *
> >     * The event loop is stopped by calling requestStop, and is
> >     * stopped after all pending events have been processed.  Any
> >     * existing pending events are always processed before performing
> >     * the first poll.
> >     */
> >
> >Obviously, there should not be existing pending events, and processing
> >them would in fact lead to an exception.
> >
> >Can you explain what you are failing to understand in my description of
> >the problem?
> >  
> >	Cheers,
> >	Kris
> >  
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]