jr at vertica.com
Wed Jul 5 21:43:37 EDT 2006
[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
> have a buffer that is of appropriate size, you're calling SP_receive
> 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
I'll have a look. C++ are us.
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
> 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
> about unnecessarily calling SP_receive twice. What you describe is
> 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.
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
More information about the Spread-users