Jan Kiszka wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> - rtnet-check-receiving.diff
>>> @@ -375,13 +379,23 @@ ssize_t rt_udp_recvmsg(struct rtdm_dev_c
>>>      struct udphdr       *uh;
>>>      struct sockaddr_in  *sin;
>>>      nanosecs_rel_t      timeout = sock->timeout;
>>> -    int                 ret;
>>> +    int                 ret, index;
>>> +    rtdm_lockctx_t  context;
>>>  
>>>  
>>>      /* non-blocking receive? */
>>>      if (testbits(msg_flags, MSG_DONTWAIT))
>>>          timeout = -1;
>>>  
>>> +    rtdm_lock_get_irqsave(&udp_socket_base_lock, context);
>>> +    if ((index = sock->prot.inet.reg_index) < 0) {
>>> +       rtdm_lock_put_irqrestore(&udp_socket_base_lock, context);
>>> +        /* socket is being closed */
>>> +       return -EBADF;
>>> +    }
>>> +    port_registry[index].receiving = 1;
>>> +    rtdm_lock_put_irqrestore(&udp_socket_base_lock, context);
>>> +       
>> This is the only part of the patch I don't like. I don't want to add
>> another lock site to the RX path. I see the problem, but I think we need
>> some other solution. Maybe something that disables reception, and thus
>> unwanted buffer consumption.
> 
> Well, I was too quick. There is another thing I don't like about this
> patch: It breaks valid use cases.
> 
> Consider some application creating a socket first, then sending some
> message, next doing something else (or being preempted for a while), and
> finally calling into the recvmsg functions. With your change a potential
> reply to that sent-out message could have been dropped in the meantime
> because the socket was not yet marked as 'receiving'. Not good.
> 
> We need an alternative approach, something that either set ups two
> buffer pools (but that might be costly memory-wise) or something that
> allows an application to actively disable reception on a socket. Given
> that your case is not a common issue, I would vote for the latter direction.

You mean like shutdown ?

-- 


                                            Gilles.

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
RTnet-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rtnet-developers

Reply via email to