> On Mon, Jul 29, 2013 at 10:55 PM, Anand Avati <anand.avati at gmail.com> > wrote: > > > I am assuming the module in question is this - > https://github.com/unbit/uwsgi/blob/master/plugins/glusterfs/glusterfs.c. > I > see that you are not using the async variants of any of the glfs calls so > far. I also believe you would like these "synchronous" calls to play > nicely > with Coro:: by yielding in a compatible way (and getting woken up when > response arrives in a compatible way) - rather than implementing an > explicit glfs_stat_async(). The ->request() method does not seem to be be > naturally allowing the use of "explictly asynchronous" calls within. > > Can you provide some details of the event/request management in use? If > possible, I would like to provide hooks for yield and wakeup primitives in > gfapi (which you can wire with Coro:: or anything else) such that these > seemingly synchronous calls (glfs_open, glfs_stat etc.) don't starve the > app thread without yielding. > > I can see those hooks having a benefit in the qemu gfapi driver too, > removing a bit of code there which integrates callbacks into the event > loop > using pipes. > > Avati > > This is a prototype of async way: https://github.com/unbit/uwsgi/blob/master/plugins/glusterfs/glusterfs.c#L43 basically once the async request is sent, the uWSGI core (it can be a coroutine, a greenthread or another callback) wait for a signal (via pipe [could be eventfd() on linux]) of the callback completion: https://github.com/unbit/uwsgi/blob/master/plugins/glusterfs/glusterfs.c#L78 the problem is that this approach is racey in respect of the uwsgi_glusterfs_async_io structure. Can i assume after glfs_close() all of the pending callbacks are cleared ? In such a way i could simply deallocate it (now it is on the stack) at the end of the request. Thanks -- Roberto De Ioris http://unbit.it
