All callbacks within the iomux context are executed on your main thread.

So yes, an App is single threaded, as long as you do not implement own threads for certain stuff.

Some libraries which we are using are also using own threads and they use thread safety structures in their implementation to queue iomux callbacks into the main thread (e.g. you need to call iomux->SetExecLocked, if you are not inside your main thread, but want to talk to it).

If you start two task one after the other, it doesn't mean that the task execution itself is queued. It depends on what your task does.

Example:

Task1 is of UWebserverGet

Task2 is of UDatabase

you call Task1->Start which itself calls IWebserverGet::Send to send a packet as an answer to a GET request, Task1 leaves the Start function and does nothing anymore

you call Task2->Start directly afterwards which calls IDatabase->ExecSQL to issue a query, Task2 leaves the Start function and does nothing anymore

Task1 is now waiting for the UWebserverGet::WebserverGetSendResult callback.

Task2 is now waiting for the UDatabase::ExecSQLResult callback.

Your app now does nothing anymore and the iomux hangs inside its epoll_wait function which is triggered on file descriptor actions.

The task callbacks are triggered within the iomux when the sockets of the database and/or the webserver are responding to your previous actions.

This now depends on which socket answers faster to which action.

So it could be that Task1::WebserverGetSendResult is called before Task2::ExecSQLResult or the other way round.

Greetings,
Daniel