[Spread-users] BUFFER_TOO_SHORT && endian_mismatch >= 0

[Jonathan Stanton]

On Wed, Jul 03, 2002 at 06:08:52PM -0400, Tim Peters wrote:
> > It looks like your num_groups also gets messed up even on successful
> > calls to receive sometimes?
> 
> I figure you're talking about this:
> 
> 		if (size >= 0) {
> 			if (num_groups < 0) {
> 				/* XXX This really happens!
> 				   Don't dare retry the receive, since we
> 				   didn't get an error.  The extra names
> 				   are forever lost. */
> 				num_groups = max_groups;
> 			}
> 			break;
> 		}
> 
> My boss added that code early on because he saw that combination happening.

The only way I can see this happening is if the DROP_RECV flag is passed
in the service type field. This flag enables the "old" behavior of
Spread prior to version 3.12. This behavior is still useful sometimes
when you do not want to retry and you just want to make progress (or the
buffer space is limited).

if DROP_RECV is enabled, then a 'successful' SP_receive call can have a
negative num_groups. This indicates that some of the groups were dropped
but the message was received. 


> It doesn't seem too surprising to me after reading the SP_receive() man
> page:
> 
>     For example, if your groups array could store 5 group names, but a
>     message for 7 groups arrived, the first five group names would
>     appear in the groups array and num_groups would be set to -7.
> 
> although I don't find the docs entirely clear about exactly when
> GROUPS_TOO_SHORT is returned.

GROUPS_TOO_SHORT should be returned whenever DROP_RECV is NOT set and
the groups array is too small. If the buffers are also too small then
GROUPS_TOO_SHORT will be set but endian_mismatch will also be negative
so you know how big a buffer is needed. 

BUFFER_TOO_SHORT is only returned if the groups array IS big enough and
DROP_RECV is not set. OR if DROP_RECV is set then it will be returned
whenever the buffer is too short, even if groups is also short. I agree
this is a slight descrepency -- it results because originally only
BUFFER_TOO_SHORT existed, GROUPS_TOO_SHORT was added when the semantics
were changed from DROP_RECV to NOT DROP_RECV by default.
> 
> Is it your testimony that GROUPS_TOO_SHORT will always be returned when
> num_groups is too small and no other kind of error return is competing for
> attention?  Even for a REG_MESSAGE, where the user may well not care about
> the group list?

Yes. Even if BUFFER_TOO__SHORT  is also true, the GROUPS_ error will
be the one returned if it is true. A REG_MESSAGE can have a large groups
list if a multi-group message is sent.

Jonathan

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