On 08/11/2013 10:23 PM, Micah Chalmer wrote:
So in general, using std I/O from outside of tasks is going to
continue to be sketchy for quite a while.
Thanks for the info, unfortunate though it may be. Given this, it
doesn't look like I should bother even trying to get anything to work
with the high level FUSE API providing its own threads. Sure, I can
get it to run some trivial rust code, but that rust code can't even
use any I/O--and I/O is the purpose of just about any reasonable
filesystem!
Raphael raised another potential issue:
libufse forks into the background when you call fuse_main() which
might make you lose it (if lib fuse uses some 'clone()' call instead
of fork()/daemon()).
Does rust's scheduler work through a fork? If not, is it still OK if
the fork happens before any other tasks are spawned? I.e. before any
rust tasks are spawned, the process forks, and the child process
continues and the parent exits without spawning. I tried a simple
test (https://gist.github.com/MicahChalmer/1f056005e29ab3f1b912) and
it didn't seem to have any problems, but are there any hidden traps
around forking to be aware of?
If you do it before starting the runtime then it's fine. Forking without
execing while the scheduler is running will likely be disastrous.
As for what I'm trying to do with libfuse, I do have a workaround:
FUSE has a low level API that can be used instead, in which it calls
the filesystem back in an asynchronous manner--instead of returning
the info the operation seeks, you call a reply function to pass it
back, and you're allowed to do so at some point after you've already
returned from the callback. The low-level API is harder to work with,
but appears to be the way to go if I want to continue working on this.
Instead of fiddling with the subset of rust that's usable without the
scheduler, I could actually use the scheduler to run each filesystem
operation in its own task.
It will be interesting to see how many of the documented rules of
usage that exist only as comments in the C API can be made enforceable
in rust's type system...
-Micah
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
