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.
No, once a socket is "receiving", it remains "receiving" until it is
closed. The only hunks that sets receiving to 0 is the creation function.
--
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
