[Spread-users] SP_poll

[John Robinson]

[responses to multiple responses interspersed below:]

Daniel F. Savarese wrote:
 > In message <44AC27C5.4060202 at vertica.com>, John Robinson writes:
 >
 >>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?
 >
 >
 > The only problem with the second approach as describd is that if you 
already
 > have a buffer that is of appropriate size, you're calling SP_receive 
twice
 > when the second call could be avoided.  Normally, you'd want to call
 > SP_receive with the buffer you've got, and only if it's too small, then
 > increase the buffer size.

In my application, I will be passing the filled [data] buffers along to 
other parts of the system, so the next receive will typically happen 
when there is no buffer left from the prior receive.  Membership-change 
messages will be handled in my spread-wrapper layer, so the buffer could 
be kept and reused in that rarer case.  Data messages should be more 
frequent by several orders of magnitude in a typical app. after all.

 >  However, if you're okay using C++, you may want
 > to consider using the Sava Spread API
 > (http://www.savarese.com/software/SavaSpread/api/).  Among other
 > things, it automatically takes care of resizing buffers so you don't 
have to.

I'll have a look.  C++ are us.

 > daniel
 >

John Lane Schultz wrote:
 > 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.

Okay.  So its result is basically "yes, there is something to receive"., 
i.e., a bool.  I was already using select() for this, so dispensing with 
SP_poll() works for me.  :-)

 >> 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.

In my experience, SP_receive really returns 0 as its length for 
self-leave messages, but still fills in the group name for you.  So I 
actually don't have to call SP_receive again with a >0 length message 
buffer.  [I am using Spread version 4].

Daniel F. Savarese wrote:
 >>In message <44AC27C5.4060202 at vertica.com>, John Robinson writes:
 >>
 >>>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
 >
 >
 > Oops!  I'm sorry.  I read that as "a message length of 0" as opposed to
 > what you actually wrote, which was "or 0".  So, please ignore my 
commentary
 > about unnecessarily calling SP_receive twice.  What you describe is 
exactly
 > how SP_receive is intended to be used.

Wonder of wonders, I actually did mean to type "of", not "or".  But I 
think it all works fine anyway.

 > daniel
 >

Many thanks Daniel and John for the prompt and helpful responses.  I 
continue to have warm fuzzies from my experience so far with Spread and 
its community.

/jr