www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Reviving Phobos

reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
I just watched my 2018 presentation on Photon, and found it 
fantastic. This boosted my morale and decided to revive Photon.

First things first I’d like Photon to be betterC compatible, the 
only thing preventing that is Fiber being coupled with Druntime. 
If only we could carve it out and package as betterC library on 
dub…

Any takers?

—
Dmitry Olshansky
Apr 11 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
*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.
Apr 11 2023
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Apr 11 2023
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
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.
Apr 11 2023