The forked elephant in the room

Richard (Rikki) Andrew Cattermole richard at cattermole.co.nz
Tue Jan 16 14:49:30 UTC 2024


On 17/01/2024 3:42 AM, ikod wrote:
> On Tuesday, 16 January 2024 at 10:13:15 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>>> I'd start from defining event loop API to decouple interface from 
>>> implementations.
>>
>> I have done this in the past. You end up defining the user experience 
>> in the process.
>>
>> Unless you go out of your way with something like coroutines, or 
>> fibers, you're pretty much stuck with callbacks of some kind and that 
>> is not going to fly.
> 
> I had no problems implementing a common API for select, poll, epoll, 
> kqueue event loops (never tried Linux io-uring or Windows completion 
> ports). This API can be declared and used for independent 
> implementations of current and future OS event systems.
> 
> On top of this implementations for tasks, timeouts, and so on can be 
> created.
> 
> Are there any reasons why this won't work?

You may have misunderstood me.

I suggested to design the user experience first, and only then build the 
event loop itself to fulfill its needs.

Anything other than that, will produce undesirable user experience 
because you did not intentionally design it. It was shoehorned on to the 
implementation of the event loop (which is the wrong way round).


More information about the Digitalmars-d mailing list