Hi Jakub. Dne 11. dubna 2012 18:53 Jakub Jermar <[email protected]> napsal(a): > On 11.4.2012 11:13, Vojtech Horky wrote: >>> It seems to me that the current implementation understands the timeouts >>> rather strictly. In other words, zero timeout indicates a very impatient >>> waiter which doesn't allow any time for the wakeup condition to become >>> true even if that would have happened instantly. I think it won't hurt >>> if the wakeup condition is given one-more non-blocking test to see if >>> the waiter can get the message. Even if the message arrived just after >>> the timeout, the caller will get the message and the timeout event will >>> be silently ignored. >> Are you referring to the ToDo in async_wait_timeout()? > > No, I was just describing the current behavior of timeout == 0. But now > when you mention it, cannot the todo be eliminated by forcing timeout to > 0 and applying your patch? That would not emit the same behavior as the todo requests. The zero timeout would cause a fibril switch (to manager) which is something the todo wants to avoid. At least as I understand it.
>> Maybe if the part around ipc_wait_cycle() would be extracted to a >> separate function that would be also called in async_wait_timeout(), >> it may work better for those impatient clients? > > I am not sure what you exactly mean here. But I was basically satisfied > with the patch, but see below. Sorry for bad explanation. See the attached patch. It deals with the todo and actually leaves the original "fairness" intact. I think this shall not break anything. And it is probably cleaner solution for the problem. >>> Please double check that calling handle_expired_timeouts() also before >>> going to ipc_wait_cycle() will not have any undesired side effects. >> I am not sure I follow. Without the patch I sent, it won't be reached >> anyway and with the patch it seems redundant. What I am missing? > > The patch changes the behavior slightly. Now it can happen that the > worker fibril will be woken up by the timeout and, in fact, can start > executing if there is another manager fibril to schedule it. The first > manager fibril will go to ipc_wait_cycle() where it may notice a message > and deliver it to a worker fibril, possibly the one which timed out. I > wonder if there can be some kind of a race when the fibril notices the > timeout, but does not notice the message. Surely, it would notice the > message on a second try. Which brings me to the following point. Are you sure this could happen in single-threaded application? > It also appears to me that, thanks to the missing free() in the handling > of the timeout in async_wait_timeout(), the framework expects that it is > possible to call async_wait() or async_wait_timeout() multiple times > until the reply eventually arrives. Otherwise I think there is a leak of That is correct (obviously, async_wait would just block and you can call it max once). And it seems to me as a sensible behavior. > msg. Would be nice to be able to say something like: "Ok, the wait timed > out, I will not call async_wait*() for the second time." to free up the > message. Do you have any practical use case in mind where this might be useful? Thanks. - Vojta > > Jakub > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
starve_possible_fix_v2.patch
Description: Binary data
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
