Hi Micah, I don't have much experience with rust but I stumbled onto a similar problem a few weeks ago. What I found out was that calling rust functions from code that have no rust-thread context will fail most often than not. Except if those functions are simple wrappers around extern c functions.
If you run something like that http://pastebin.mozilla.org/2824359, the c function runs fine but the `println` aborts with "fatal runtime error: thread-local pointer is null. bogus!" (and some Lovecraft excerpt??). If you're not in a rust thread you can't access the tls so I'd say you can expect most std::* functions that allocate/access tlsmemory to fail the same way. Have you thought about patching libfuse to use rust threads instead? This would probably be a whole lot of work, but then I think you could use rust in your fuse callbacks transparently. Another, probably simpler/saner, way would be to use the single-threaded option and then spawn a new rust thread in each callback. You have to ensure that the callbacks are called from a rust context though. I think that libufse forks into the background when you call fuse_main() which might make you lose it (if libfuse uses some 'clone()' call instead of fork()/daemon()). In this case you should pass the '-f' option to fuse_main() to prevent it and you should retain the rust context. Good luck! On Sat, Aug 10, 2013 at 8:30 AM, Micah Chalmer <[email protected]> wrote: > 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 _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
