[Spread-users] SP_poll

[John Lane Schultz]

John Robinson wrote:
> Hi spread-lovers,
> 
> I tried creating a test based on examples/user.c, but using SP_poll (so 
> I can size the receive buffer from malloc()), and noticed some odd 
> results, at least when all the traffic is membership messages.  The 
> SP_poll seems to return the wrong length most of the time, and sometimes 
> it is too small.  See the first output log below.  [trust me that the 
> program is doing what it claims it is].

SP_poll is meant more to indicate file descriptor activity than the actual size 
of any pending message(s).  It basically just polls the file descriptor to see 
how much data can be read immediately.  File descriptors, of course, have no 
knowledge of Spread message structures and so SP_poll is inappropriate for 
sizing receive buffers.

Think of SP_poll basically as a simplistic version of a non-blocking read 
select() on a single file descriptor that returns whether or not it is ready for 
read activity.

> So I realized that I can just use SP_receive to do the work of SP_poll, 
> in effect.  The first call uses a message length or 0, and then uses the 
> error in BUFFER_TOO_SHORT to get the correct size buffer.  This seems to 
> have the extra advantage that for self-leave messages, no allocation is 
> needed at all.
> 
> Is there any reason I shouldn't follow the second approach?

Actually, this is a very common method of calling receive to appropriately size 
dynamically created buffers.  Self-leave messages still have message bodies *I 
think* and should therefore return the BUFFER_TOO_SHORT error too.  Transitional 
messages do not have message bodies and can be received successfully in this manner.

-- 
John Schultz
Spread Concepts LLC
Phn: 443 838 2200
Fax: 301 560 8875