[e-lang] E and FUSE-j integration

David Hopwood david.hopwood at industrial-designers.co.uk
Wed Sep 26 16:20:26 EDT 2007


Toby Murray wrote:
> How would one go about trying to implement the synchronous FUSE API
> using E's asynchronous remote messaging model?

It is worth pointing out that a synchronous API is bad design in this
case: it requires a round-trip for every file operation.

> (I suspect the solution here would be a general one that could be
> applied to other situations in which one needs to implement a
> synchronous interface using remote references.)

It's possible to do that using a binary semaphore or equivalent.
Something like (*untested code*):

# see
# http://java.sun.com/javase/6/docs/api/java/util/concurrent/Semaphore.html

def unsafeWaitFor(v) :any {
   def semaphore = <unsafe:java.util.concurrent.Semaphore>.new(-1, false)
   def succeeded :boolean
   def vOutside :any
   def probOutside: any

   when (v) -> {
      succeeded := true
      vOutside := v
      semaphore.release();
   } catch prob {
      succeeded := false
      probOutside := prob
      semaphore.release();
   }
   semaphore.acquire();
   if (!succeeded) throw probOutside
   return vOutside
}

def myFileSystemProxy {
   to getattr(path, getattrSetter) :any {
      return unsafeWaitFor(remote <- foo(arg))
   }
   ...
}

This is "unsafe" in the sense of subverting the event loop concurrency
model, which should be discouraged unless absolutely necessary.

> Also, another potential problem is that FUSE has its own event loop. A
> call to mount a filesystem returns only when the filesystem is
> unmounted. Hence, there appears to be conflict between two competing
> event loops -- E's and FUSE's.

The vat that handles requests from FUSE just has to have its own runner
thread, I think.

-- 
David Hopwood <david.hopwood at industrial-designers.co.uk>




More information about the e-lang mailing list