Hi Rust devs, What can I assume about the safety of having a C library spawn its own threads, from which it calls function pointers to "extern" functions written in rust? My guess (and only a guess--I have no actual reasoning behind it) would be something like this:
* I cannot expect anything involving tasks or the task scheduler to work properly in this situation. That means no spawning tasks, no use of ports and chans, and no use of @ boxes. * I can expect plain "c-like" rust code to work, subject to the same rules about thread safety as the equivalent C code. That could include borrowed references and ~ boxes. Rust's rules ensure basic memory integrity within each thread (except for unsafe blocks/fns), but I would still have to be aware of potential race conditions, just as if I were writing C in the same situation. If my guesses are true, how much of the standard library can I use? What functions make assumptions about threads and the runtime behind the scenes in non-obvious ways? Is there a way to know? Will there be? If my guesses are false, I would appreciate a correct view of the situation. I've already been able to get very simple "c-like rust code" to work in a situation like this, but I haven't done enough testing to have any confidence in it. There could be hidden race conditions/crashes that would eventually appear, even for the simple case--my tests may have just "accidentally worked." Why this came up for me: As a "curiosity project," I decided I'd see if I could write an interface to the Fuse library to the point where I'd be able to create a working userspace filesystem in rust. At this point all it does is implement the minimum interface required to get a rust version of the FUSE tutorial "hellofs" working. When writing a filesystem using the high-level FUSE API, the filesystem is expected to call the "fuse_main" function and pass it a structure full of pointers to its own functions. FUSE then runs its main loop and calls the passed-in functions when a filesystem operation is requested. By default, FUSE will spawn its own OS threads and may call the filesystem functions from any of them. It's possible to force the library to run single-threaded, but at the cost of performance--it can no longer perform more than one file system operation at a time. You can see the barely-started WIP at https://github.com/MicahChalmer/rust-fuse if you're curious. I plan to post again to the list when it's in some sort of shape that would be worth looking at for its own sake, but I'm writing now because of the question above. Thanks -Micah _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
