Jan Kiszka writes: > 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.
Then it should be OK as it is in vulcano CVS now. 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
