[Spread-users] GROUPS_TOO_SHORT || BUFFER_TOO_SHORT

Jonathan Stanton jonathan at cnds.jhu.edu
Mon Mar 18 18:18:33 EST 2002


On Mon, Mar 18, 2002 at 06:09:36PM -0500, David Shaw wrote:
> What would be really nice here would be a bit set to indicate that
> this truncation had actually happened.  For example, an application
> that did not care if its messages were truncated or not (but did want
> to know if it happened) could always pass DROP_RECV.  A bit set
> (perhaps in service_type) would indicate that the truncation was
> necessary.  If the message did happen to fit in the buffer, then
> DROP_RECV had no effect and the bit would not be set.
> 
> This allows for simpler application code and can halve the number of
> calls into the Spread library (and halve the number of thread locks,
> etc.).

Maybe I'm missing something in what you say, but what you want is exactly what
happens if you pass DROP_RECV in the service field of every message. The
message will be truncated if it is too long and you will be notifed by the
error return code. You will only make one call into SP_recv for every message
and if they fit it will be all ok, if they don't it will be truncated and you
willknow you lost data.

If you do not pass DROP_RECV you will also be notifed by an
error return code, but the data won't be truncated and the message will still
be waiting for you to call sp_recv again. This allows you to get zero loss of
data because of short buffers at teh cost of having to call sp-recv twice in
those cases.

Maybe it wasn't clear that teh return code error is returned in both cases.
Now, since it isn't a bitset, but an int, only one error can be returned. So
either GROUPS_TOO_SHORT or BUFFER_TOO_SHORT  will be returned. If teh groups
is too short groups error will be returned, if the groups is ok, but buffer is
too short then buffer_to_short will be returned. If both are too short, I
think groups_to_short is returned since that is tested first, but I'd have to
double check the code.

Jonathan

-- 
-------------------------------------------------------
Jonathan R. Stanton         jonathan at cs.jhu.edu
Dept. of Computer Science   
Johns Hopkins University    
-------------------------------------------------------





More information about the Spread-users mailing list