<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 29, 2013 at 8:36 AM, Roberto De Ioris <span dir="ltr"><<a href="mailto:roberto@unbit.it" target="_blank">roberto@unbit.it</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi everyone, i have just committed a plugin for the uWSGI application server<br>
for exposing glusterfs filesystems using the new native api:<br>
<br>
<a href="https://github.com/unbit/uwsgi-docs/blob/master/GlusterFS.rst" target="_blank">https://github.com/unbit/uwsgi-docs/blob/master/GlusterFS.rst</a><br>
<br>
Currently it is very simple, but works really well.<br>
<br>
I have studied the whole api, and i have two questions:<br>
<br>
why there is no glfs_stat_async() ?<br>
<br>
if i understand the code well, even stat() is a blocking operation.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My objective is avoiding the use of threads and processes and use the<br>
uWSGI async api to implement a non blocking-approach (mixable with other<br>
engines like gevent or Coro::AnyEvent)<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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".</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another thing is the bison/yacc nameclash. uWSGI allows you to load<br>
various external libraries and the use of the default 'yy' prefix causes<br>
nameclashes with common libraries (like matheval).<br>
<br>
I understand that matheval too should choose a better approach, but why<br>
not prefixing it like glusterfsyy ? This would avoid headaches, even for<br>
when people will start using the library in higher level languages.<br>
<br>
Currently i have tried the YFLAGS env var hack for ./configure but it did<br>
not work (i am using bison)<br>
<br>
YFLAGS="-Dapi.prefix=glusterfsyy -d" ./configure --prefix=/opt/glusterfs/<br></blockquote><div><br></div><div>Hmm, this is nice to get fixed. Do you already have a patch which you have used (other than just the "technique" shown above)?</div>
<div><br></div><div><br></div><div>Thanks!</div><div>Avati</div><div><br></div></div></div></div>