On 08/10/2013 06:27 AM, raphael catolino wrote:
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.
This is probably because println is using `std::io` which erroneously
uses GC in a few places. Very unfortunate. Of course this is going to
take a lot of effort to solve in the new runtime too since the default
I/O implementation will depend on the scheduler event loop. We're likely
to have two implementations of each of the I/O types: one that uses the
event loop and one that doesn't. In a situation like this where
`println` doesn't have access to the scheduler I would expect it to
dynamically choose the native, blocking I/O implementation. It's a lot
of effort to get there though.
So in general, using std I/O from outside of tasks is going to continue
to be sketchy for quite a while.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
