Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> 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.
>
> Well, not binding to a specific port is the standard pattern for client
> applications. And clients start their work with sending some packet to a
> server. So this use case is surely not unusual.
I would expect client applications to try to bind their socket to a
given port range, not to rely on the UDP stack to choose one in an
unknown range. This way, you get things working behind a firewall...
--
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
