[Gluster-users] uWSGI plugin and some question
Roberto De Ioris
roberto at unbit.it
Tue Jul 30 14:47:35 UTC 2013
> On Mon, Jul 29, 2013 at 10:55 PM, Anand Avati <anand.avati at gmail.com>
> I am assuming the module in question is this -
> 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
> 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
> using pipes.
This is a prototype of async way:
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:
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.
Roberto De Ioris
More information about the Gluster-users