[Spread-users] Spread with non-blocking I/O

John Schultz jschultz at spreadconcepts.com
Mon Dec 1 10:20:24 EST 2003

Martin Waite wrote:
> Hi,
> Is it safe to use Spread with non-blocking I/O ?
In a certain sense, yes.  The Spread client library right now does not 
perform non-blocking reads as this would require the library to 
send/store partial messages.  If you are connected to a remote daemon 
and the connection dropped while a large message is in transit, then you 
could block.

> I would like to write a select()- or poll()-based 
> network listener that collects requests from the 
> network and forwards them to request handlers 
> via Spread.
You can use select/poll/sp_event to detect when there is activity on the 
connection.  Essentially, the Spread library assumes that once some of 
the data for a message is available, then all of it will be there really 

This assumption is very valid when using IPC, as the daemon has the 
complete message already and will push it over the pipe as quickly as 
possible (if the daemon dies, then the pipe should fail very quickly 
too).  If you are connecting remotely to a daemon, then there is some 
small chance that you could actually block for a _long_ period of time 
(e.g. - tcp connection timeout) in a call to sp_receive or sp_multicast 
(if the daemon dies or the network disconnects), even after the socket 
indicated read/write readiness.

> I understand that the Spread mailbox is a file-handle
> and so select() should tell me when data is available 
> for reading/writing.  

> However, does the availability 
> of data on the file handle guarantee that the call 
> to sp_receive() will not block ?
No -- it can block under the scenario above discussed.  But, if you use 
IPC then I'd say yes, although it might be more blocking'ish (i.e. - 
slower) than say socket calls using normal non-blocking I/O.

> Can I use the Spread Event subsystem to handle 
> non-blocking I/O and give this control over my listening 
> socket and accepted connections ?
Sure, but the event subsystem is based on a select loop so it will have 
the same problems.

John Lane Schultz
Spread Concepts LLC
Phn: 443 838 2200

More information about the Spread-users mailing list