Re: Strange Thread behaviour with FUSE Python

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Strange Thread behaviour with FUSE Python

Nikolaus Rath
Nikolaus Rath <[hidden email]> writes:

> Hello,
>
> If I insert
>
> def mythread():
>     while True:
>         print "Logging Thread active"
>         sleep(2)
> import threading
> from time import sleep
> threading.Thread(target=mythread).start()
>
> into the example xmp.py script right before the server.main() call (and
> keep server.multithreaded = False), I get the following result:
[...]

> Does anyone have an idea what might cause this totally different
> behaviour? I'm not even sure where to start looking for the problem.

Sometimes the strangest looking problems have the easiest solutions. It
turns out that

 - my own file system exits with sys.exit() at the end (thus killing the
   other threads) while xmp.py doesn't have an explicit exit and waits
   for the last thread.

 - xmp.py handles requests to fast for the background thread to activate
   while handling. A simple sleep(1) in the request handler makes the
   background threads come alive.

   
So the behaviour is at least consistent.

However, I am still surprised by the implementation of single threading.
I would have expected that this affects only the number of threads that
collect requests from the fuse kernel module. Is there a specific reason
why all other program threads are stopped and started with the one
request handling thread? Or is that just a side-effect of the design?
   

Best,

   -Nikolaus

--
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Strange Thread behaviour with FUSE Python

Csaba Henk
On 2009-05-27, Nikolaus Rath <[hidden email]> wrote:
> So the behaviour is at least consistent.
>
> However, I am still surprised by the implementation of single threading.
> I would have expected that this affects only the number of threads that
> collect requests from the fuse kernel module. Is there a specific reason
> why all other program threads are stopped and started with the one
> request handling thread? Or is that just a side-effect of the design?

I could produce three kind of behaviours in single-threaded mode (using
a variant of the "nullfs" scheme, modded with a logging thread as you
suggest) (which, from a bird-eye perspective, should be the same, comme
ci, comme ca):

- "My"[*] fuse-python binding, as is. Here happens what you posted: the
  logging thread is sleeping until the fs server thread terminates.

- My fuse-python binding, with the modification that instead of directly
  calling fuse_setup() and then fuse_loop(), we invoke fuse_main(). I
  experienced that the logging thread is awaken each time the fs server
  gets a message.

- Verigakis' binding (http://code.google.com/p/fusepy/), relying on
  ctypes (instead of using a C extension). This code invokes
  fuse_main() thru ctypes. It does what (I guess) you would expect:
  the logging thread is active throroughout the whole fs session.

Given that, in fact, fuse_main == fuse_setup + fuse_loop, these three
should produce the same thing. This is not the case though. Do you have
any idea why? If you don't, I might end up with writing to
comp.lang.python. Anyway, I don't have the faintest clue by myself.

It's interesting information provided by strace(1) that with the
Verigakis bindings, the logging thread is not doing futex(2) calls at
all, while in the other two cases, futexes are massively relied on.

Csaba


[*] of course, not mine, Seb Delafond's


------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Strange Thread behaviour with FUSE Python

Nikolaus Rath
Csaba Henk <[hidden email]> writes:

> On 2009-05-27, Nikolaus Rath <[hidden email]> wrote:
>> So the behaviour is at least consistent.
>>
>> However, I am still surprised by the implementation of single threading.
>> I would have expected that this affects only the number of threads that
>> collect requests from the fuse kernel module. Is there a specific reason
>> why all other program threads are stopped and started with the one
>> request handling thread? Or is that just a side-effect of the design?
>
> I could produce three kind of behaviours in single-threaded mode (using
> a variant of the "nullfs" scheme, modded with a logging thread as you
> suggest) (which, from a bird-eye perspective, should be the same, comme
> ci, comme ca):
>
> - "My"[*] fuse-python binding, as is. Here happens what you posted: the
>   logging thread is sleeping until the fs server thread terminates.

Have you tried to insert some additional time.sleep() calls into the
handler functions? As I wrote in my followup, for me the logging thread
wasn't actually sleeping, it just had no time to wake up.

> - My fuse-python binding, with the modification that instead of directly
>   calling fuse_setup() and then fuse_loop(), we invoke fuse_main(). I
>   experienced that the logging thread is awaken each time the fs server
>   gets a message.

That would also make this consistent with the above.

> - Verigakis' binding (http://code.google.com/p/fusepy/), relying on
>   ctypes (instead of using a C extension). This code invokes
>   fuse_main() thru ctypes. It does what (I guess) you would expect:
>   the logging thread is active throroughout the whole fs session.
>
> Given that, in fact, fuse_main == fuse_setup + fuse_loop, these three
> should produce the same thing. This is not the case though. Do you have
> any idea why? If you don't, I might end up with writing to
> comp.lang.python. Anyway, I don't have the faintest clue by myself.

No, I'm afraid I don't have any idea either...


Best,

   -Nikolaus

--
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel