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. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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
