[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 

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.


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