|
From: | Anand Avati |
Subject: | Re: [Gluster-devel] [Gluster-users] uWSGI plugin and some question |
Date: | Tue, 30 Jul 2013 22:01:21 -0700 |
> I am assuming the module in question is this -This is a prototype of async way:
> 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
>
>
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.
[Prev in Thread] | Current Thread | [Next in Thread] |