Tsoding - How Not to Market Your Language Features

[Derek Fawcus]

On Friday, 28 March 2025 at 17:04:58 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
> 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.

The fiber is only part of the answer.  My point in raising Alef 
was to show that one doesn't actually need migration between 
threads, an alternative is viable. It rather depends upon how one 
wishes to handle i/o.

>
>> 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.

Nope.  That is the goroutine as implemented by the Google gc 
compiler.  The goroutines as implemented by GCC can call out to C 
(they run as threads).

The two concepts are orthogonal, it is the fact that gc 
goroutines have an automatic user space thread scheduler and its 
minimal initial stack which makes calling to C awkward, not the 
calling convention per-se.


Now my prefered form would be something like the Alef scheme, but 
is an optional user space scheduler.  Then one can easily have 3 
forms of concurrent stackful routines. However I've yet to try 
coding that up, and so don't have anything to point to.