From: Goswin v. B. <gos...@we...> - 2009-03-05 07:39:59
|
Marcos Dione <md...@gr...> writes: > On Wed, Mar 04, 2009 at 06:27:58PM -0200, Marcos Dione wrote: >> as I mentioned before, I'm (slowly) working in a python binding for >> the lowlevel api. as the low level api is asynchronous, does it make any >> sense to make it support threads as well? I only found locks on >> requests, but I'm not really sure no any other threaded code affects >> fuse_lowlevel.c. is low level API threaded in any way? Compare /** * Enter a single threaded event loop * * @param se the session * @return 0 on success, -1 on error */ int fuse_session_loop(struct fuse_session *se); and /** * Enter a multi-threaded event loop * * @param se the session * @return 0 on success, -1 on error */ int fuse_session_loop_mt(struct fuse_session *se); > also, and maybe put in other words, is there any assurances that > only one request is issued at a time? what happens if the code uses > another asyncronous library to get the data? besides the loops clashing > (there already are questions about integrating libfuse in a qt4 program > in the archives), is there anything else one should be careful about? > clearly I can't wrap my head around the problem (even if there is one or > not), so these vague questions is all I can think of, sorry. See the thread on argument validity for some details. In short the problem is that arguments are only valid until the callback returns. For example the buffer passed to the write callback expires once the callback returns. If you need it past that then you have to copy it. So it isn't really asynchronous yet. MfG Goswin |