From: Greg Millam <ruby-talk@...>
Date: 2005-09-17T13:16:38+09:00
Subject: Re: FuseFS, and ruby threading issues

Well, I've figured out how to keep ruby in control, so threads, sockets,
etc work just fine.

I've found that I can't make it allow recursive calls, so I'm just
leaving that up to the programmer and user.

Meantime: I have a working initial FuseFS, a little project that I'd
like some usability input on.

http://walker.deafcode.com/code/fusefs.tar.gz

NOTE: It is NOT an implementation of the fuse API - it is a small
implementation that is intended to make making FUSE filesystems easy.

It includes a database->filesystem mapping (sqlfs.rb), and a demo
filesystem that just includes simple tests like a 'colors' file that
prints a diffrent color every time it's 'cat'ted.

Note that this version only has read-only support. I am working on write
support, but am still thinking on how I want to do this.

Have fun and please let me know of any bugs or any ideas you may have.

- Greg Millam

On Sat, Sep 17, 2005 at 08:58:54AM +0900, Greg Millam wrote:
> This one's mostly for folks who know how ruby deals with threads inside
> and out.
> 
> I have a little project, FuseFS, to provide a userland filesystem
> entirely defined in Ruby. (Note: This is *not* rfuse, and is not a
> direct implementation of the FUSE api. It is my intention to provide a somewhat
> rubyish interface. That is: FuseFS is to FUSE as WEBrick is to the HTTP
> protocol + TCPSocket.)
> 
> The use of FUSE has given me a few limitations:
> 
> * fuse_main literally takes over the program. So "FuseFS.run" basically
>   hands control of the app over to fuse. It does correctly call Ruby
>   methods. However, Threads() will not work, and this will likely
>   interfere with anybody who wants to write, say, a GMailFS clone or
>   anything using sockets.
> 
> * Without pthread support, FuseFS will be unable to deal with concurrent
>   calls. This also means it can't have anything that reads other files
>   in itself, and will hang indefinitely until kill -9'd.
> 
> What are my options, here? Can I have Ruby stand in its "own" thread,
> and when a fuse thread gets an event, have it feed to the ruby thread,
> then feed back? (Kinda polling-ish) ? etc?
> 
> Any ideas and opinions appreciated.
> 
> Thanks,
> 
> - Greg Millam
>