[Gluster-users] uWSGI plugin and some question

[John Mark Walker]

Hi Roberto,

Wow, this looks really awesome - thank you so much for taking the time to
do this.

I am copying the gluster-devel list, as they may have some insight into the
more dev-centric questions.

Also, if you're so inclined, please consider mirroring your project on the
Gluster Community Forge, which is the standard place for all Gluster-y
things to be developed: http://forge.gluster.org/

Thanks,
John Mark
Gluster Community Leader



On Mon, Jul 29, 2013 at 11: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.
>
> 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)
>
> 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/
>
> Thanks a lot for your attention
>
> --
> Roberto De Ioris
> http://unbit.it
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130729/dc39a0d5/attachment.html>