I think it works well for C / C++, but that wasn't my point.

I'm talking about alternate language bindings -- implementing FUSE interfaces in languages other then C / C++.  For example just in recent threads there has been mention of C#, Perl, OCaml, and others. 

Like I said before, some language runtimes require that they manage their own threads.  If threads are created externally in libfuse and then call back into the language runtime (via the callbacks), then that can cause race conditions, corruption, seg faults, etc.

The reason this is difficult to work around is that in the syncronous model, control does not return from a callback until the results are ready.  So in order to have thread support, it has to be before the level of the callbacks -- in the event loop.

With the asynchronous model, it should be possible to (optionally) leave thread handling code to the filesystem implementation level.  Having that option would allow some language bindings to make use of libfuse without being forced to run in single-threaded mode..

Valient

On Thu, 2004-11-18 at 20:15 -0500, Paul Alfille wrote:
I hope we don't change the current model. Letting fuse be multithreaded,
and having your code control (via mutexes or whatever) non-sharable
resources has proven to be a very powerful model.

OWFS (http://owfs.sf.net) does exactly that. In fact, I use the same
library to bind against fuse for a file system, and to bind against a
simple web server for browser access. The web server code is more
complex, requiring threading support, and  workarounds for uclibc. Fuse
on the other hand takes care of all that.

At first I thought I'd have to modify the thread creation code in
libfuse to have control of thread starting and passing information. The
solution proved much simpler. I found that I can restrict access to
limited resources (my 1-wire bus, and individual devices) without
knowing anything of the global number of fuse threads.