[Gluster-devel] [Gluster-users] uWSGI plugin and some question

[Roberto De Ioris]

> 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