Tsoding - How Not to Market Your Language Features

[Richard (Rikki) Andrew Cattermole]

On 29/03/2025 6:28 AM, Derek Fawcus wrote:
> 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.

You need that migration to take advantage of the advanced event loops 
like IOCP.

They utilize their own thread pool where work is given to whatever 
thread is available, no preference.

Otherwise you're stuck doing what vibe.d does. If you care about safety 
of course.

>>> 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 gccgo compiler implements goroutines using a technique called 
segmented stacks, supported by recent modifications to the gold linker. 
Gollvm similarly is built on the corresponding LLVM infrastructure."

https://go.dev/doc/faq

Is this out of date?

Because that is still using the read barriers and is still implemented 
using a different calling convention that we have indeed eliminated.

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

I've read the implementation, it'll error if you try.