[Spread-users] SP_kill() calls in SP_receive and multicast calls
John Lane Schultz
jschultz at spreadconcepts.com
Fri Sep 15 12:04:03 EDT 2006
Hi Alec,
This race condition has been removed in Spread 4. Now the only way a
mailbox/descriptor will be closed is through an explicit call by the user to
either SP_disconnect or SP_kill. This allows the user to do the proper
synchronization between threads to ensure each thread is talking on the proper
mailbox.
We believe that this is a strictly better way of handling shutting down
mailboxes and do not intend to support the previous behavior any longer.
Cheers,
John
Alec H. Peterson wrote:
> Greetings all,
>
> We use Spread as part of an event-based system, and we perform
> select()-ish behavior on the mbox file descriptor. We ran into a
> problem recently where our scheduler will assert a 'duplicate file
> descriptor' crash when Spread is unexpectedly disconnected. We tracked
> this down to the fact that if any of the SP_ calls detect a system call
> failure on the mbox, they call SP_kill() on the mbox before returning.
> This is a very, very bad race condition for systems (like ours) that
> track events based on file descriptor. We've modified our local version
> of Spread to just not call SP_kill() in these situations, but we're
> curious if this behavior could be modified in future releases of
> Spread. Specifically, some sort of session-wide option could be set
> after connect to preclude the closing from happening, which would
> preserve the prior behavior for backward compatibility. However, I am
> not sure just removing the SP_kill() calls is that bad a thing, as I
> believe an application is supposed to call SP_disconnect() whenever it
> receives a fatal error from one of the SP_ calls...
>
> Thanks,
>
> Alec
>
>
> _______________________________________________
> Spread-users mailing list
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users
>
--
John Schultz
Spread Concepts LLC
Phn: 443 838 2200
Fax: 301 560 8875
More information about the Spread-users
mailing list