*whispers* https://github.com/Project-Sidero/basic_memory

Currently being working on: https://github.com/Project-Sidero/eventloop

However my stuff won't help you. I want more guarantees, not less. Yes it is -betterC, which only drives it harder. Since you don't want this to be valid D:

```d
MyRef myRef = ...;
auto mem = myRef.get;
myRef.destroy;
//use mem
```

Not only could that not segfault, but it could still have valid data in mem's memory. Which is a very scary possibility.

I gotta say what I've been able to build so far is very impressive. Having dmd build DLL's that look and feel like regular in binary code? (ok ignoring a few workarounds...). Along with supporting druntime in executable, with GC and druntime thread integration? Muhaha.



But as far as fibers are concerned? Kill them off. They are a target + platform + system C compiler ABI hack. They waste GC time scanning memory which has no valid data in it.

The solution should be coroutines. Superior in basically every way. But you need language assistance to make them nice. I.e. this is not the nice way to do it (but do-able):

```d
Coroutine myCoroutine() {
    static struct State {

    }

    enum Stages {
        Start,
        Second,
    }

    CoroutineBuilder!(State, Stages, int) builder;
    builder[Stages.Start] = (scope ref state) {
        //return builder.result(2);
        SystemHandle sysHandle;
        return builder.nextStage(Stages.Second).after(handle);
    };

    return builder.build();
}
```



In terms of Phobos itself, it just needs leadership. After all, how many years has it been since we found out that console support on Windows should NOT be done with C standard IO? Cos that would be an easy module to write up.

On Tuesday, 11 April 2023 at 17:49:55 UTC, Richard (Rikki) Andrew Cattermole wrote:
> *whispers* https://github.com/Project-Sidero/basic_memory
>

I allocate all of my memory at startup in Photon.

> Currently being working on: https://github.com/Project-Sidero/eventloop
>
> However my stuff won't help you. I want more guarantees, not less. Yes it is -betterC, which only drives it harder. Since you don't want this to be valid D:
>
> ```d
> MyRef myRef = ...;
> auto mem = myRef.get;
> myRef.destroy;
> //use mem
> ```

Manual refcounting been there done that.

> Not only could that not segfault, but it could still have valid data in mem's memory. Which is a very scary possibility.
>
> I gotta say what I've been able to build so far is very impressive. Having dmd build DLL's that look and feel like regular in binary code? (ok ignoring a few workarounds...). Along with supporting druntime in executable, with GC and druntime thread integration? Muhaha.

Cool.

>
>
> But as far as fibers are concerned? Kill them off. They are a target + platform + system C compiler ABI hack. They waste GC time scanning memory which has no valid data in it.
>
> The solution should be coroutines.

I like coroutines in Kotlin for that matter, the only downside is suspendable vs nonsuspendable functions.


>
> In terms of Phobos itself, it just needs leadership. After all, how many years has it been since we found out that console support on Windows should NOT be done with C standard IO? Cos that would be an easy module to write up.

Yup.

—
Dmitry Olshanky

On 12/04/2023 5:56 AM, Dmitry Olshansky wrote:
>> But as far as fibers are concerned? Kill them off. They are a target + platform + system C compiler ABI hack. They waste GC time scanning memory which has no valid data in it.
>>
>> The solution should be coroutines.
> 
> I like coroutines in Kotlin for that matter, the only downside is suspendable vs nonsuspendable functions.

From my research into them, what I've concluded is you have leaf, mergable and non-mergable functions.

Leaf of course is a coroutine, mergable gets merged into a given coroutine or can be used as non-mergable, and of course non-mergable which is just regular D functions that we have now.

And of course you can't access TLS in a fiber/coroutine as they could move between threads, although in saying that there are reasons why you shouldn't do that due to the way system resources like locks work.

Certainly desirable thing to have, but alas its only QoL, not memory safety or makes linking possible so that is so far on the back burner I'm not thinking about how to actually get that in.