Tsoding - How Not to Market Your Language Features

[Richard (Rikki) Andrew Cattermole]

On 29/03/2025 5:35 AM, Derek Fawcus wrote:
> On Friday, 28 March 2025 at 14:15:01 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> On 29/03/2025 12:41 AM, Dukc wrote:
>>>     Also many approaches are expecting async/await behavior
>>>
>>> Is this a problem for D? Doesn't Vibe.D, or even just Phobos, handle 
>>> this just fine?
>>
>> No.
>>
>> D's Fiber's cannot move between threads safely, and there is a limit 
>> on the number you can have at the kernel level due to the usage of pages.
>>
>> We cannot recommend a solution to drive modern event loops (circa late 
>> 90's), due to safety concerns and these limitations. Note the word 
>> recommend, it is important here!
>>
>> Hence why we need stackless coroutines to fill in that gap ;)
> 
> Actually, one could have light weight stackful coroutines within the 
> system, and user space switching.  Have a look at what Alef had - the 
> predecessor to Limbo and Go.
 >
> It had 'procs' and 'tasks'.  The former being implemented simply as 
> kernel level threads, hence preemptively scheduled by the kernel, the 
> latter as user level coroutines within such a thread.  The same scheme 
> ended up as libthread for C on plan9.

We have that, its called a Fiber.

> One should be able to create a libthread like facility for D, and given 
> the GC it should be almost as usable as the CSP scheme in Go.  The 
> difference being the lack of preemption between 'tasks', vs the 
> preemption which happens with goroutines.

A goroutine effectively has its own calling convention. That cannot call 
out to C.

We have dismissed that as an option.

> As to stackless coroutines, I personally find the too much hassle, 
> hiding some (but not all) of the detials and complexities of their 
> underlying state-machine implementation.

Whatever solution we have that is to be recommended it must be thread 
safe, can be moved between threads and can have a lot of them (like over 
100K/s). Oh and must also be able to call C.

The only solution that matches that, and is known to be a mature concept 
in use with these requirements is stackless coroutines.

Everything else fails some part of the requirements.

> About the only thing I'd say they have going for them is they sort of 
> are flavour of the month, and C++ has sort of done the same thing.  But 
> then I'm biased, I prefer the CSP / Actor approach.

I'm exploring actors as the event handling abstraction for windowing.

However you'd still use coroutines as part of this. They are complimentary.