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
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>
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>