On 19 September 2013 13:35, Jakub Jermar <ja...@jermar.eu> wrote: > On 09/19/2013 12:13 PM, Jiří Zárevúcky wrote: > > [...] > > > > I think you missed the point of this patch. The goal is not to introduce > > a new synchronization primitive, but to abstract away parts of > > fibril-related code. In a sense, I have not added anything - I have > > taken functionality that is already used throughout the library, and > > hidden it behind a well-defined waiting interface. This way, other code > > (not just fibril_synch, but async and ipc as well) can use this > > interface instead of messing with fibril scheduler. > > Got it. There is also some missed opportunity for some additional > cleanup - see the attached patch.
Thanks. > So how about the timeouts? So I just looked at how the async framework supports them, and it seems timeouts can't be cleanly included as part of fibril API, since they are currently handled as an indivisible part of waiting for IPC. Three possibilities of what to do about it: a) Keep a small amount of dependency on async framework in the fibril API. b) Use async framework timers in condvar implementation. c) Spawn a dedicated thread for dealing with timers, and handle them completely independent of IPC. And when we > are at it, wouldn't it be possible to implement the sleeping in the > async framework via this? > > Yes, using the same abstraction in async framework is the next logical step. In fact, I was thinking about simplifying what the framework does a bit. IMO there can be a single ordinary fibril running in async framework, periodically checking for new messages. fibril_yield() would return whether there is another fibril running, and if not, it would mean that the currently running thread is the only active one and can be suspended until IPC arrives. This would erase the distinction between manager and non-manager fibrils, which would simplify the code further. -- Jirka Z.
_______________________________________________ HelenOS-devel mailing list HelenOS-devel@lists.modry.cz http://lists.modry.cz/listinfo/helenos-devel
