> 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?
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
