Hi Jakub,
thanks for looking into this.

Dne 10. dubna 2012 16:14 Jakub Jermar <[email protected]> napsal(a):
> Hi Voljta,
>
> On 9.4.2012 22:15, Vojtech Horky wrote:
>> It seems to me that the current implementation is
>> trying to be fair: once something was done (expired timeouts were
>> handled), the manager fibril switches to a normal fibril to give
>> chance to other fibrils to run.
>
> 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()?

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?

>
> 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?

- Vojta

>
> +                               timeout = 0;
> +                               flags = SYNCH_FLAGS_NON_BLOCKING;
>
> I don't think you need to clear timeout as SYNCH_FLAGS_NON_BLOCKING will
> make the kernel ignore it.
>
> Jakub
>
> _______________________________________________
> HelenOS-devel mailing list
> [email protected]
> http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Reply via email to