[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