On 2008-07-13 08:28:24 -0700, Christiaan Hofman <[EMAIL PROTECTED]> said:
> Adam, I hope you still see this. I am a bit uncertain whether
> BDSKAsynchronousDOServer is stopped properly. Especially if the server
> thread runloop is stopped, and whether -cleanup is guaranteed to be
> executed. I could imagine the following errors to occur:
>
> 1. send -cleanup
> 2. set shouldKeepRunning to 0
> 3. server thread runloop finishes some long calculation, no new
> runloop run as shouldKeepRunning == 0
>
> Result:
> -cleanup is never run, because there is no runloop to pick it up
Sounds plausible. I'm not sure of a way around this, since turning "&&
didRun" into "|| didRun" means that the thread could keep running
forever unless all the inputs are removed, so it would no longer be a
guaranteed stop mechanism.
> 1. send -cleanup
> 2. serverThread executes -cleanup immediately
> 3. server thread starts new runloop run
> 4. set shouldKeepRunning to 0
>
> Result:
> the runloop on the server thread never finishes, as it gets no input
> anymore
This also seems possible, although invalidating the connection may
tickle the runloop. Having only thought about this briefly, a safe
workaround might be to do this in cleanup:
OSAtomicCompareAndSwap32Barrier(1, 0, (int32_t
*)&serverFlags->shouldKeepRunning);
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode
beforeDate:[NSDate distantPast]];
which would ensure the runloop exits. Alternately, running it with a
short timeout in runDOServerForPorts: instead of +[NSDate
distantFuture] would work. IIRC I use the finite timeout for a similar
problem in FVConcreteOperationQueue.
In fact, setting shouldKeepRunning = 0 in -cleanup would solve the
first problem, also (I think), providing the message doesn't get
dropped. There may be some subtle reason it's set in the main thread,
but there's no comment to that effect.
> Am I right that this could happen? As you may know I am not very well
> at run loops and threads.
That makes two of us...I think you made a good catch. There are a lot
of tricky issues to get right, especially with teardown of the
connection and the async message sends. I'm less enamored with this
class now that Apple no longer recommends using DO for interthread
communication. NSOperationQueue and OFMessageQueue require less
tweaking, although the latter is only good for void messages.
--
adam
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bibdesk-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
