[rust-dev] Met with a terrible fate

Isak Andersson contact at bitpuffin.com
Thu Jul 3 01:44:26 PDT 2014


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 <alex at 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 <contact at 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 at mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140703/9529996c/attachment.html>


More information about the Rust-dev mailing list