Re: [RTnet-developers] Maintaining UDP sockets in a hash instead of a list.

[Gilles C. <gil...@xe...>]

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.

It seems I was too quick to admit your use case: would such an
application do this without binding the socket to another port than the
automacically assigned port ? Because once a socket is bound to a port
no received packet is lost.

-- 


					    Gilles.