Paolo Mantegazza wrote: > Jan Kiszka writes: >> Paolo Mantegazza wrote: >>> M. Koehrer wrote: >>>> Hi Dennis, >>>> I have just detected the very same effect. At least with RTAI-3.3cv >>>> it is not working. >>>> In rtnet's rt_udp_recvmsg() >>>> the timeout will be set to -1 if the flag MSG_DONTWAIT is used. >>>> The call to rtdm_sem_timeddown() with this timeout value fails as >>>> the resulting RTAI >>>> function _sem_wait_timed rejects a negative timeout => it returns >>>> -EWOULDBLOCK immediately >>>> without checking the semaphores value. >>>> RTDM in RTAI seems not to handle a polling semaphore check correctly. >>>> That means the only possible way (without changing rtdm) is to it >>>> the way you have done it: >>>> Using a extreme small timeout value (=1). >>>> By looking at the code I saw same strange things: >>>> In rtnet, the time type nanosecs_t is a uint64, however in RTAI's >>>> rtdm the timetype is a signed int64. >>>> That could lead to confusion... >>>> To fix the MSG_DONTWAIT issue I have detected, the code can be >>>> modified to set the timeout >>>> to 1 (instead of -1) whenever MSG_DONTWAIT is specified. >>> >>> Negative timeouts produce -EWOULDBLOCK in the original >>> implementation of RTDM also. The difference is that there the sem >>> count check is anticipated and the count simply decremented with >>> immediate return if it is greater than zero. RTAI checks for >>> -EWOULDBLOCK before and so it does not call its timed sem_wait, where >>> the sem count will be decremented, withoutn any timeout, if it is >>> greater then zero. So it will behave as expected. >>> Clearly the solution woulfd be to use 0, but it cannot, as zero >>> indicates an infinite delay in RTDM. So one (nanosec) has to be the >>> compromise. Notice it will never produce any delay, either because >>> sem count is greater than zero or because it is too low a value and >>> RTAI will timeout immediately anyhow, as it is never worth to have to >>> reschedule for a single nanosec. >> >> rtdm_sem_timeddown: >> "This function tries to decrement the given semphore's value if it is >> positive on entry. If not, the caller is blocked unless non-blocking >> operation was selected." >> I read my one text here, so I may interpret it implicitly as I want it >> to be. But to me it sounds like: "Try to get the sem first, then block >> or fail." >> Please consider fixing RTAI's RTDM layer, e.g. by mapping timeouts < 0 >> to timeout = 1. It's the intention of RTDM to keep the semantic >> consistent over all platforms. > > Is a negative timeout meant as sem_trywait _ALWAYS_?
Yep, that's what I tried to express. Not that clearly only in the sentence above, but in combination with the parameter list: "@param[in] timeout Relative timeout in nanoseconds, 0 for infinite, or any negative value for non-blocking operation" The same goes for mutexes and events, BTW. But events already look correct, and mutexes will be fixed automatically when changing semaphores. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
