[Gluster-users] uWSGI plugin and some question

[Anand Avati]

On Mon, Jul 29, 2013 at 8:36 AM, Roberto De Ioris <roberto at unbit.it> wrote:

>
> Hi everyone, i have just committed a plugin for the uWSGI application
> server
> for exposing glusterfs filesystems using the new native api:
>
> https://github.com/unbit/uwsgi-docs/blob/master/GlusterFS.rst
>
> Currently it is very simple, but works really well.
>
> I have studied the whole api, and i have two questions:
>
> why there is no glfs_stat_async() ?
>
> if i understand the code well, even stat() is a blocking operation.
>

Can you show some code in uwsgi which makes use of asynchronous stat calls?
Adding an async stat call in gfapi is not hard, but the use case hasn't
been clear.


> My objective is avoiding the use of threads and processes and use the
> uWSGI async api to implement a non blocking-approach (mixable with other
> engines like gevent or Coro::AnyEvent)
>

Are there any requirements that the callback happen only in specific
threads? That is typically a common requirement, and the async callbacks
would end up requiring special "wiring" to bring the callbacks to desired
threads. But I guess that wiring would already be done with the IO
callbacks anyways in your case.

Do you have some prototype of the module using gfapi out somewhere? I'm
hoping to understand the use case of gfapi and see if something can be done
to make it integrate with Coro::AnyEvent more "naturally".


> Another thing is the bison/yacc nameclash. uWSGI allows you to load
> various external libraries and the use of the default 'yy' prefix causes
> nameclashes with common libraries (like matheval).
>
> I understand that matheval too should choose a better approach, but why
> not prefixing it like glusterfsyy ? This would avoid headaches, even for
> when people will start using the library in higher level languages.
>
> Currently i have tried the YFLAGS env var hack for ./configure but it did
> not work (i am using bison)
>
> YFLAGS="-Dapi.prefix=glusterfsyy -d" ./configure --prefix=/opt/glusterfs/
>

Hmm, this is nice to get fixed. Do you already have a patch which you have
used (other than just the "technique" shown above)?


Thanks!
Avati
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130729/bac7061b/attachment.html>