mystran wrote:
To prevent conflicts from concurrently run callbacks, it has a concept of coloring, with the simple rule that no two events of the same color will ever be run at the same time...
This works, but is a drag on the developer and hard to get right. "What color did we use for UI events?". It abstracts the main problem to "groups of events" and allows you to place arbitrary labels on each group, you being somebody who is probably not qualified to make that distinction. You will merge events that have no correlation and separate events that should be merged.
The point behind the color is "group of correlated events". If you can group all events explicitly or implicitly you can guarantee them to be ordered in the order they were sent. This is exactly why my own implementation at the moment lacks a little bit about MP invocations - at the moment it counts on everything locking its own data structures and just plain blocking the thread it receives for execution. I wasn't directly concerned about the threads (which is a basic problem but an architectural one that is abstracted away) but more about the reliability - you need a fair mutex with queueing or the order won't be guaranteed.
The "coloring" does appear to have merit now I think about it a bit more. It appears to be isomorph to the other solutions I had in mind but it is implementable, whilst the ideas I had in memory weren't.
Quote:
The paper I read, also mentions multi-color events in passing, so I kinda started thinking: if one allows several colors per event and guarantees that no two concurrently running events share any of the colors, then allows dynamic allocation of the colors and dynamic coloring of the events, then associates different colors to different data-structures (or parts of data-structures), then one essentially ends up with all the locking in the same place (the multi-threaded event-loop), and completely avoids potential for dead-locks (in the worst case the system would degenerate into a single-threaded event-loop if no two events can run concurrently, but would not completely dead-lock).
Yep.
On the other hand, that requires you to know about all data structures, their internals, what they can and cannot do, how they interact and so on. I would not like you to color my FIFO for one-at-a-time use since it's intended to do two.
I see more future in the direction of join calculus.
Quote:
some sort of deferred procedure call mechanism
Nice name ->
My deferred calls