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_? Paolo. ------------------------------------------------------------------------- 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
