Hi, thanks for your quick replies! I am thinking that maybe one solution could be that the C code calls an init function that calls native::start and provides a function pointer that start calls back into C. That way the C main thread will have a rust runtime in the background, I *think*?.
I hope this would be possible at least, the important thing is that it can be in the main thread, as often mobile platforms require to run in the main thread because the GUI library needs it for some reason. At least in iOS. (I am building a helper lib for making apps easier with our service) Other than that I don't really know how much I can restructure my code to work without (objective-)C(#) not having to do anything special. The way the library will be structured is that it has an internal thread where it runs at operation queue. Once that operation queue is empty the thread terminates and if you add more operations to the queue the thread starts once again. So a lot of the code will run in its own thread, which is at least good. However some of the code will work outside of the operation queue for things like queries that might use some kind of mutex to make sure it's not querying something that the operation queue is already processing. And for those mutexes to work it probably has to be within the same native::start... Unless I can use some kind of unsafe C mutex thing. Thoughts? Cheers! On Thu, Jul 3, 2014 at 3:23 AM, Alex Crichton <a...@crichton.co> wrote: > If you touch runtime services (such as those mentioned by Benjamin), > it is assume that a Rust Task [1] is available. In your case, you're > touching the unwinding service, but you have no set a catch-point for > the call to unwinding anywhere. This sounds like you're triggering a > failure without a task. This is akin to throwing a C++ exception > without a try/catch block on the stack. > > You may wish to explore the std::rt::unwind [2] module, specifically > the try function [3], but keep in mind that it is unsafe and you must > be careful about what you're doing (the documentation explains this). > > I love getting the runtime running in nonstandard locations, so if you > have any trouble, feel free to ping me on IRC! My nick is acrichto. > > > [1]: http://doc.rust-lang.org/std/rt/task/struct.Task.html > [2]: http://doc.rust-lang.org/std/rt/unwind/ > [3]: http://doc.rust-lang.org/std/rt/unwind/fn.try.html > > On Wed, Jul 2, 2014 at 6:07 PM, Isak Andersson <cont...@bitpuffin.com> > wrote: > > Hello! > > > > I have written a library in Rust that has some pub extern fv's in it so > that > > they are callable from C. I wrote a C program to try calling these > functions > > and I was met with the following message: > > > > % ./test > > > > You've met with a terrible fate, haven't you? > > > > fatal runtime error: Could not unwind stack, error = 5 > > zsh: illegal hardware instruction ./test > > > > To begin with, nice reference! > > > > Second of all. How do I fix this, I am guessing that I need to start the > > rust runtime or something but I don't know how to do this, if someone > could > > point me in the right direction that would be great! > > > > If you need more specific code examples of what I'm doing I can provide > it > > it's just that I'm gonna sleep now and it doesn't seem like that's all > too > > relevant. Also I did link to the libraries in the order it told me to. > > > > Cheers! > > > > Isak Andersson > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev@mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
