[Linux-ha-dev] Re: [Linux-ha-cvs] Linux-HA CVS: lib by gshi from

[Alan Robertson]

Alan Robertson wrote:
> Guochun Shi wrote:
> 
>> At 03:54 PM 2/23/2005 -0700, you wrote:
>>
>>> linux-ha-cvs at lists.linux-ha.org wrote:
>>>
>>>> linux-ha CVS committal
>>>> Author  : gshi
>>>> Host    : Project : linux-ha
>>>> Module  : lib
>>>> Dir     : linux-ha/lib/clplumbing
>>>>
>>>> Modified Files:
>>>>       ipcsocket.c Log Message:
>>>> if channel is not connected,
>>>> a blocking send should return IPC_FAIL
>>>> ===================================================================
>>>> RCS file: /home/cvs/linux-ha/linux-ha/lib/clplumbing/ipcsocket.c,v
>>>> retrieving revision 1.123
>>>> retrieving revision 1.124
>>>> diff -u -3 -r1.123 -r1.124
>>>> --- ipcsocket.c 11 Feb 2005 21:39:35 -0000      1.123
>>>> +++ ipcsocket.c 23 Feb 2005 18:05:29 -0000      1.124
>>>> @@ -1,4 +1,4 @@
>>>> -/* $Id: ipcsocket.c,v 1.123 2005/02/11 21:39:35 alan Exp $ */
>>>> +/* $Id: ipcsocket.c,v 1.124 2005/02/23 18:05:29 gshi Exp $ */
>>>> /*
>>>> * ipcsocket unix domain socket implementation of IPC abstraction.
>>>> *
>>>> @@ -767,6 +767,11 @@
>>>>       }
>>>>             while (ch->send_queue->current_qlen >= 
>>>> ch->send_queue->max_qlen){
>>>> +               if (ch->ch_status != IPC_CONNECT){
>>>> +                       cl_log(LOG_ERR, "socket_send:"
>>>> +                       " message queue exceeded and IPC not 
>>>> connected");
>>>> +                       return IPC_FAIL;
>>>> +               }
>>>>               cl_shortsleep();
>>>>               ch->ops->resume_io(ch);
>>>>       }
>>>
>>>
>>> I reread this code in context...  It's not as obvious as it could 
>>> be... BUT, setting that aside...
>>>
>>> What is this "should_send_blocking" mode on the IPC channel?  The 
>>> whole idea of this IPC code is that it should NEVER block.
>>>
>>> And, there doesn't appear to be any way to set this 
>>> "should_send_blocking" flag on either...
>>
>>
>>
>> There is no api to do that but a client can set it directly. By 
>> default IPC code is never blocked There are cases a client may want to 
>> wait until the send is done
> 
> 
> 
> There is an explicit API call for that already.  This is why I didn't 
> understand this...


Is this the call you put in to make the tests (that don't do flow control) 
work easily?

If so, I guess I understand it now...

-- 
     Alan Robertson <alanr at unix.sh>

"Openness is the foundation and preservative of friendship...  Let me claim 
from you at all times your undisguised opinions." - William Wilberforce