Maybe you have overseen it, because I only mention it in a small comment: 
In my example the external library starts a background thread for processing which will later invoke callback.
Therefore it is not a Rust -> C -> Rust stack but a C -> Rust stack.
While this avoids blocking the Rust task ;) I also agree that this is a special case. I think there are both kinds of C libraries. Some will execute code and perform callbacks only on the callers thread and others will perform the callbacks on their own threads.
My intention was to inform further about challenges and solutions for the last model. During the last years I gathered a lot of expierence with libraries operating in such a way and how they were integrated into applications. And unfortunatly I had to discover that most people were doing it wrong because they did not know or did not care about threading.
So my idea was to give some aid about how to handle this in Rust.
I consider the callbacks which are executed from a Rust context/stack much easier, therefore I chose to not give them that much attention Maybe the chapter should be extended to start with Rust -> C -> Rust chains and afterwards explain the asynchronous C -> Rust stuff.