[Spread-users] Spread and select

[Hua Zhong]

Hi John,

Thanks for the reply. 

> Hua Zhong wrote:
> 
> >Good, but there are a couple of issues:
> >1. it's not documented, thus making me wonder if it's officially 
> >supported feature. In fact, there is not even a 
> SP_mailbox_to_fd kind of helper. How could one assume mailbox 
> == fd? It's implementation details that could change anytime, 
> and nothing to depend on.
> >  
> >
> 
> You can count on a mailbox being a socket descriptor in 
> Spread.  If that isn't in the official documentation right 
> now, then we'll be sure to add it with the new release.

That would be great!
 
> >2. there is still not a non-blocking version SP_receive. As 
> I explained earlier, it's not very nice to programers.
> 
> You are correct that right now there is no non-blocking 
> version of SP_receive.  This was a decision made a long time 
> ago in Spread's development.  The idea was that if there is 
> activity on the file descriptor (i.e. - incoming data), then 
> the entire incoming message should be there "soon."  It is 
> true that this can cause blocking behavior if, for example, 
> the TCP/IP link between the client and server is slow for some reason.

Actually, I am not mainly worried about slow TCP/IP connections. I am worried about the race that a poll returns "there is data",
and when the time of receive comes, the data has been gone. In a lot of cases we want an atomic non-blocking "poll+receive". People
writing software in such a model try very hard to do any blocking calls, it's just the way it is.

> The real way to make SP_receive non-blocking is to have each 
> connection store partial messages internally when it blocks 
> until it has collected an entire message that it can deliver. 
>  By default, the maximum Spread msg size is ~100K.  In the 
> past, we were reluctant to complicate the client library 
> further and either always allocate 100K per connection or 
> dynamically allocate memory as necessary.

I am not sure if I've got what you are saying, but a non-blocking SP_receive should never, erh, block.

It should work this way:

1) if there is no data, return -EAGAIN;
2) if there is data, read it. If the data is only a partial message, store it in a static buffer for each mailbox (which has max of
100K), and return -EGAIN.
3) if there is complete data now in the buffer, return the message to caller.

There is never blocking. The caller would have to expect SP_receive_nb() to return EGAIN even if SP_poll tells there is data. It's
the whole point of having non-blocking calls: SP_poll never promises a complete message.

Since it would be a new API, it doesn't break any current applications.

If you think this is a good enhancement, I'm willing to send you a patch.

Hua