ThreadToRunIn

The callback should be only run by the same thread that set it.

The UI thread is a special one - it is the supervisor of the workers and the controller of gui and console handles. It is the first thread to call arsd_core_init actively running an event loop unless there is a thread that has actively asserted the ui supervisor role. FIXME is this true after i implemen it?

A ui thread should be always quickly responsive to new events.

There should only be one main ui thread, in which simpledisplay and minigui can be used.

Other threads can run like ui threads, but are considered temporary and only concerned with their own needs (it is the default style of loop for an undeclared thread but will not receive messages from other threads unless there is no other option)

Ad-Hoc thread - something running an event loop that isn't another thing Controller thread - running an explicit event loop instance set as not a task runner or blocking worker UI thread - simpledisplay's event loop, which it will require remain live for the duration of the program (running two .eventLoops without a parent EventLoop instance will become illegal, throwing at runtime if it happens telling people to change their code)

Windows HANDLES will always be listened on the thread itself that is requesting, UNLESS it is a worker/helper thread, in which case it goes to a coordinator thread. since it prolly can't rely on the parent per se this will have to be one created by arsd core init, UNLESS the parent is inside an explicit EventLoop structure.

All use the MsgWaitForMultipleObjectsEx pattern

The callback can be called from any available worker thread. It will be added to a global queue and the first thread to see it will run it.

These will not run on the UI thread unless there is no other option on the platform (and all platforms this lib supports have other options).

These are expected to run cooperatively multitasked things; functions that frequently yield as they wait on other tasks. Think a fiber.

A task runner should be generally responsive to new events.

These are expected to run longer blocking, but independent operations. Think an individual function with no context.

A blocking worker can wait hundreds of milliseconds between checking for new events.

The callback will be duplicated across all threads known to the arsd.core event loop.

It adds it to an immutable queue that each thread will go through... might just replace with an exit() function.

so to cancel all associated tasks for like a web server, it could just have the tasks atomicAdd to a counter and subtract when they are finished. Then you have a single semaphore you signal the number of times you have an active thing and wait for them to acknowledge it.

threads should report when they start running the loop and they really should report when they terminate but that isn't reliable

hmmm what if: all user-created threads (the public api) count as ui threads. only ones created in here are task runners or helpers. ui threads can wait on a global event to exit.

there's still prolly be one "the" ui thread, which does the handle listening on windows and is the one sdpy wants.