[rust-dev] Met with a terrible fate

Isak Andersson contact at bitpuffin.com
Thu Jul 3 08:41:48 PDT 2014

Aright great! I'll give it a try and let you all know if there is issues.

I'll check the link as well, thank you!


Isak Andersson

On Thu, Jul 3, 2014 at 3:58 PM, Alex Crichton <alex at crichton.co> wrote:

> > 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*?.
> That is correct!
> > 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)
> This is indeed possible! We have many many applications and games
> being written in Rust right now, and they all have the same
> requirement.
> > 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.
> Right now the C => Rust FFI bridge isn't as convenient as it could be.
> One option you may want to look into is what rust-civet [1] does which
> is to create a new native rust task per-request, but it doesn't spawn
> a thread per request.
> [1]: https://github.com/wycats/rust-civet/blob/master/src/raw.rs#L91-L106
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140703/8a8c8e83/attachment.html>

More information about the Rust-dev mailing list