[rust-dev] Met with a terrible fate

Alex Crichton alex at crichton.co
Thu Jul 3 06:58:19 PDT 2014


> 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


More information about the Rust-dev mailing list