www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Photon v0.12.1 with 50% faster eventloop

reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
So big news is that on Linux (and soon on other platforms) 
eventloop was rewritten to run faster especially in chatty apps 
that do lots of smallish send/recv ping pong. The end result is 
50% faster end-to-end memcached benchmark for my up and coming 
hedgehog[1] server. It's now actually 15-20% faster than stock 
memcached on memtier benchmark and about 50% faster on memcslap 
tests I carried out, this is far from extensive benchmarking and 
hedgehog is not even that optimized yet(!)

Of other notable additions is support for AArach64 on Linux. I 
basically spun up virtual machine on my Mac and to my dismay 
AArch64 was not supported yet so I fixed it making the code more 
portable going forward.

All in all I find that fibers can deliver as long as we are not 
going into millions of connections.

1. https://github.com/DmitryOlshansky/hedgehog


--
Dmitry Olshansky
CEO   Glowlabs
https://olshansky.me
Jul 28
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Monday, 28 July 2025 at 19:57:41 UTC, Dmitry Olshansky wrote:

 So big news is that on Linux (and soon on other platforms) 
 eventloop was rewritten to run faster especially in chatty apps 
 that do lots of smallish send/recv ping pong. The end result is 
 50% faster end-to-end memcached benchmark for my up and coming 
 hedgehog[1] server. It's now actually 15-20% faster than stock 
 memcached on memtier benchmark and about 50% faster on memcslap 
 tests I carried out, this is far from extensive benchmarking 
 and hedgehog is not even that optimized yet(!)

 [...]


And ofc I forgot the obligatory link:

https://github.com/DmitryOlshansky/photon
Jul 28
parent reply Salih Dincer <salihdb hotmail.com> writes:
On Monday, 28 July 2025 at 20:02:41 UTC, Dmitry Olshansky wrote:

 And ofc I forgot the obligatory link:

 https://github.com/DmitryOlshansky/photon


Undoubtedly, Photon is a good piece of software, because the 
passing years have taught us a lot. Especially when you mentioned 
its nature, you said that Photon’s nature is dual. I sense that 
you have an interest in physics, and therefore in science, and I 
feel the names were not chosen by coincidence.

We (my colleagues and I) use loops in electronics as well. After 
all, isn’t life itself a loop? I’d like to benefit from Photon 
for microcontrollers too. Let me give an example: when branching 
from the main loop to a subroutine—which can even be another 
microcontroller on a separate PCB—you momentarily step away from 
other tasks, forced by me to do so. In a way, when one 
microcontroller sleeps, the other wakes up and practically takes 
over the operations. It strongly resembles a relay race. You also 
seem to be doing things similar to what we do in electronics. 
After all, threads are almost like independent circuits.

Wishing you success...

SDB 79
Aug 01
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Saturday, 2 August 2025 at 05:27:04 UTC, Salih Dincer wrote:

 On Monday, 28 July 2025 at 20:02:41 UTC, Dmitry Olshansky wrote:

 And ofc I forgot the obligatory link:

 https://github.com/DmitryOlshansky/photon


 Undoubtedly, Photon is a good piece of software, because the 
 passing years have taught us a lot. Especially when you 
 mentioned its nature, you said that Photon’s nature is dual. I 
 sense that you have an interest in physics, and therefore in 
 science, and I feel the names were not chosen by coincidence.


I have BSc in applied math and physics. Indeed the name was 
chosen very specifically. Unfortunately Ali Baba written their 
own fiber scheduling runtime called photon. I’m not sure if I was 
the first but ofc now living in the shadow of the big tech.


 We (my colleagues and I) use loops in electronics as well. 
 After all, isn’t life itself a loop? I’d like to benefit from 
 Photon for microcontrollers too. Let me give an example: when 
 branching from the main loop to a subroutine—which can even be 
 another microcontroller on a separate PCB—you momentarily step 
 away from other tasks, forced by me to do so. In a way, when 
 one microcontroller sleeps, the other wakes up and practically 
 takes over the operations. It strongly resembles a relay race. 
 You also seem to be doing things similar to what we do in 
 electronics. After all, threads are almost like independent 
 circuits.


Cooperative multitasking could be indeed spread across a fleet of 
MCUs, it is tricky but could provide the benefit of simple mental 
model while programming such a board.


 Wishing you success...


There is a lot to tackle still.


 SDB 79
Aug 02
prev sibling next sibling parent reply IchorDev <zxinsworld gmail.com> writes:
On Monday, 28 July 2025 at 19:57:41 UTC, Dmitry Olshansky wrote:

 So big news is that on Linux (and soon on other platforms) 
 eventloop was rewritten to run faster especially in chatty apps 
 that do lots of smallish send/recv ping pong. The end result is 
 50% faster end-to-end memcached benchmark for my up and coming 
 hedgehog[1] server. It's now actually 15-20% faster than stock 
 memcached on memtier benchmark and about 50% faster on memcslap 
 tests I carried out, this is far from extensive benchmarking 
 and hedgehog is not even that optimized yet(!)

 Of other notable additions is support for AArach64 on Linux. I 
 basically spun up virtual machine on my Mac and to my dismay 
 AArch64 was not supported yet so I fixed it making the code 
 more portable going forward.

 All in all I find that fibers can deliver as long as we are not 
 going into millions of connections.


Well done! Are there any plans to integrate this project into 
vibe.d's eventcore?
Jul 31
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Thursday, 31 July 2025 at 12:48:18 UTC, IchorDev wrote:

 On Monday, 28 July 2025 at 19:57:41 UTC, Dmitry Olshansky wrote:

 All in all I find that fibers can deliver as long as we are 
 not going into millions of connections.


 Well done! Are there any plans to integrate this project into 
 vibe.d's eventcore?


Eventcore is too low-level interface to meaningfully improve 
upon. I’m cautiously optimistic about vibe.d core fork working on 
top of photon. It would then integrate with the rest of the 
vibe.d. To be honest it seems like vibe.d core is too high level, 
while eventcore is too low level, photon is somewhere in between.

—
Dmitry Olshansky
CEO   Glowlabs
https://olshansky.me
Aug 01
parent IchorDev <zxinsworld gmail.com> writes:
On Friday, 1 August 2025 at 08:35:49 UTC, Dmitry Olshansky wrote:

 On Thursday, 31 July 2025 at 12:48:18 UTC, IchorDev wrote:

 Well done! Are there any plans to integrate this project into 
 vibe.d's eventcore?


 Eventcore is too low-level interface to meaningfully improve 
 upon. I’m cautiously optimistic about vibe.d core fork working 
 on top of photon. It would then integrate with the rest of the 
 vibe.d. To be honest it seems like vibe.d core is too high 
 level, while eventcore is too low level, photon is somewhere in 
 between.


Well, good luck then!
Aug 05
prev sibling parent reply GL <gleb.tsk gmail.com> writes:
On Monday, 28 July 2025 at 19:57:41 UTC, Dmitry Olshansky wrote:



 All in all I find that fibers can deliver as long as we are not 
 going into millions of connections.


Cool, really cool!
Thank you.

But unfortunately, Photon is not compatible with zmq (zmqd). So 
pity...
Aug 11
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Monday, 11 August 2025 at 17:44:23 UTC, GL wrote:

 On Monday, 28 July 2025 at 19:57:41 UTC, Dmitry Olshansky wrote:



 All in all I find that fibers can deliver as long as we are 
 not going into millions of connections.


 Cool, really cool!
 Thank you.



 But unfortunately, Photon is not compatible with zmq (zmqd). So 
 pity...


That would be something I could look into. I think it should be 
easily fixable. Do you have some examples that fail?

—
Dmitry Olshansky
CEO   GlowLabs
https://olshansky.me
Aug 12
parent reply GL <gleb.tsk gmail.com> writes:
On Tuesday, 12 August 2025 at 14:14:04 UTC, Dmitry Olshansky 
wrote:

 That would be something I could look into. I think it should be 
 easily fixable. Do you have some examples that fail?


Hello!
Shure:

import zmqd;

    zmqd.Context context;
    zmqd.Socket rec;

    context = Context();
    rec = Socket(context, SocketType.pull);

----------

Invalid argument (src/poll.cpp:159)
Error Program exited with code -6
Aug 13
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Wednesday, 13 August 2025 at 09:46:07 UTC, GL wrote:

 On Tuesday, 12 August 2025 at 14:14:04 UTC, Dmitry Olshansky 
 wrote:

 That would be something I could look into. I think it should 
 be easily fixable. Do you have some examples that fail?


 Hello!
 Shure:

 import zmqd;

    zmqd.Context context;
    zmqd.Socket rec;

    context = Context();
    rec = Socket(context, SocketType.pull);

 ----------

 Invalid argument (src/poll.cpp:159)
 Error Program exited with code -6


Cool, so it dies on poll. Since poll is intercepted by photon, 
there is something I failed to account for. Let's see if I can 
get it fixed.
Aug 13
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Wednesday, 13 August 2025 at 10:08:17 UTC, Dmitry Olshansky 
wrote:

 On Wednesday, 13 August 2025 at 09:46:07 UTC, GL wrote:

 On Tuesday, 12 August 2025 at 14:14:04 UTC, Dmitry Olshansky 
 wrote:

 That would be something I could look into. I think it should 
 be easily fixable. Do you have some examples that fail?


 Hello!
 Shure:

 import zmqd;

    zmqd.Context context;
    zmqd.Socket rec;

    context = Context();
    rec = Socket(context, SocketType.pull);

 ----------

 Invalid argument (src/poll.cpp:159)
 Error Program exited with code -6




So that was trivial mistake in handling -1 argument to poll.

Some more digging around and I've got the following to work:

import std.stdio;
import zmqd;
import photon;
import core.thread;

void main()
{
	startloop();
	shared bool terminated = false;
	go({
     	//  Socket to talk to clients
		auto responder = Socket(SocketType.rep);
		writeln("Got socket");
		responder.bind("tcp://*:5555");
		writeln("Binded socket");

		while (!terminated) {
			ubyte[10] buffer;
			responder.receive(buffer);
			writefln("Received: \"%s\"", cast(string)buffer);
			Thread.sleep(1.seconds);
			responder.send("World");
		}
	});
	go({
		writeln ("Connecting to hello world server...");
		auto requester = Socket(SocketType.req);
		requester.connect("tcp://localhost:5555");

		foreach (int requestNbr; 0..10)
		{
			ubyte[10] buffer;

			if (requestNbr == 9) terminated = true;
			requester.send("Hello");
			requester.receive(buffer);

		}
	});
	runFibers();
}

I need to think a little more about it but I would likely ship it 
in the next release. Soonish :)
Aug 13
next sibling parent reply GL <gleb.tsk gmail.com> writes:
On Wednesday, 13 August 2025 at 13:28:26 UTC, Dmitry Olshansky 
wrote:


 I need to think a little more about it but I would likely ship 
 it in the next release. Soonish :)


Thank you!
I will wait with great impatience...
Aug 16
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Saturday, 16 August 2025 at 09:43:02 UTC, GL wrote:

 On Wednesday, 13 August 2025 at 13:28:26 UTC, Dmitry Olshansky 
 wrote:


 I need to think a little more about it but I would likely ship 
 it in the next release. Soonish :)


 Thank you!
 I will wait with great impatience...


With new version v0.12.2 basic ZeroMQd example runs fine. Of 
other things HTTP server finally scales very well up to 48 cores 
and is faster than anything I've tried. (see photon-http 0.5.4)

https://github.com/DmitryOlshansky/photon/blob/master/tests/zmq.d

https://code.dlang.org/packages/photon

https://code.dlang.org/packages/photon-http

If you have more ZeroMQ code to test I'd gladly do it.
Aug 16
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Saturday, 16 August 2025 at 14:51:45 UTC, Dmitry Olshansky 
wrote:

 On Saturday, 16 August 2025 at 09:43:02 UTC, GL wrote:

 On Wednesday, 13 August 2025 at 13:28:26 UTC, Dmitry Olshansky 
 wrote:


 I need to think a little more about it but I would likely 
 ship it in the next release. Soonish :)


 Thank you!
 I will wait with great impatience...


 With new version v0.12.2 basic ZeroMQd example runs fine. Of 
 other things HTTP server finally scales very well up to 48 
 cores and is faster than anything I've tried. (see photon-http 
 0.5.4)


Actually that should be 0.5.5 :)

And v0.13.0 brings new feature - offload to run compute intensive 
tasks outside of scheduler. Certain syscalls are automatically 
routed through it to avoid blocking fibers such as file I/O. Here 
is simple example using goOnSameThread to make sure we are 
actually sharing just a single eventloop thread out of many and 
yet it doesn't block.

import photon;

double gauss(double a, double b, double function(double) f, 
double step) {
     double sum = 0.0;
     for (double x = a; x < b; x += step) {
         sum += (f(x+step) + f(x))/2 * step;
     }
     return sum;
}

void boom() {
     throw new Exception("Boom!");
}

long fib(long n) {
     if (n <= 2) return 1;
     else {
         return offload(() => fib(n-1)) + offload(() => fib(n-2));
     }
}

void main() {
     startloop();
     go({
         goOnSameThread({
             writeln("Blocking computation");
             writeln("Integral:", gauss(0.0, 10.0, x => x*x, 
1e-7));
         });
         goOnSameThread({
             writeln("Blocking computation");
             writeln("Integral:", gauss(0.0, 10.0, x => x*x, 
1e-7));
         });
         goOnSameThread({
             writeln("Nonblocking computation");
             writeln("Integral: ", offload(() => gauss(0.0, 10.0, 
x => x*x, 1e-7)));
         });
         goOnSameThread({
             writeln("Nonblocking computation");
             writeln("Integral: ", offload(() => gauss(0.0, 10.0, 
x => x*x, 1e-7)));
         });
         goOnSameThread({
             writeln("Catching exception from offloaded 
computation");
             try {
                 offload(&boom);
                 assert(0);
             } catch(Exception e) {
                 assert(e.msg == "Boom!");
             }
         });
         goOnSameThread({
             writeln("Recursive offload");
             writeln("Fib(15):", offload(() => fib(15)));
         });
     });
     runFibers();
}

Other photon examples:
https://github.com/DmitryOlshansky/photon/tree/master
Aug 18
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Monday, 18 August 2025 at 15:20:14 UTC, Dmitry Olshansky wrote:

 On Saturday, 16 August 2025 at 14:51:45 UTC, Dmitry Olshansky 
 wrote:

 [...]


 Actually that should be 0.5.5 :)

 And v0.13.0 brings new feature - offload to run compute 
 intensive tasks outside of scheduler. Certain syscalls are 
 automatically routed through it to avoid blocking fibers such 
 as file I/O. Here is simple example using goOnSameThread to 
 make sure we are actually sharing just a single eventloop 
 thread out of many and yet it doesn't block.

 import photon;

 double gauss(double a, double b, double function(double) f, 
 double step) {
     double sum = 0.0;
     for (double x = a; x < b; x += step) {
         sum += (f(x+step) + f(x))/2 * step;
     }
     return sum;
 }

 void boom() {
     throw new Exception("Boom!");
 }

 long fib(long n) {
     if (n <= 2) return 1;
     else {
         return offload(() => fib(n-1)) + offload(() => 
 fib(n-2));
     }
 }

 void main() {
     startloop();
     go({
         goOnSameThread({
             writeln("Blocking computation");
             writeln("Integral:", gauss(0.0, 10.0, x => x*x, 
 1e-7));
         });
         goOnSameThread({
             writeln("Blocking computation");
             writeln("Integral:", gauss(0.0, 10.0, x => x*x, 
 1e-7));
         });
         goOnSameThread({
             writeln("Nonblocking computation");
             writeln("Integral: ", offload(() => gauss(0.0, 
 10.0, x => x*x, 1e-7)));
         });
         goOnSameThread({
             writeln("Nonblocking computation");
             writeln("Integral: ", offload(() => gauss(0.0, 
 10.0, x => x*x, 1e-7)));
         });
         goOnSameThread({
             writeln("Catching exception from offloaded 
 computation");
             try {
                 offload(&boom);
                 assert(0);
             } catch(Exception e) {
                 assert(e.msg == "Boom!");
             }
         });
         goOnSameThread({
             writeln("Recursive offload");
             writeln("Fib(15):", offload(() => fib(15)));
         });
     });
     runFibers();
 }

 Other photon examples:
 https://github.com/DmitryOlshansky/photon/tree/master


I tried to include all the sources of photon in a application 
that it's cross-compiled to linux (Pi5, AArch64) and cross-linked 
with some C libs, and I'm seeing this:

```
2025-08-31T16:22:18.438 [error] extern(C) private ssize_t 
close(int fd) nothrow
src/photon/linux/core.d(1150,27):        Previous IR type: i32 
(i32)
src/photon/linux/core.d(1150,27):        New IR type:      i64 
(i32)
```

In linux.core.d: extern(C) private ssize_t close(int fd) nothrow

but `man 2 close` is `int close(int fd)`, it's a bug?
Aug 31
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Sunday, 31 August 2025 at 14:38:27 UTC, Paolo Invernizzi wrote:

 On Monday, 18 August 2025 at 15:20:14 UTC, Dmitry Olshansky 
 wrote:

 [...]


 I tried to include all the sources of photon in a application 
 that it's cross-compiled to linux (Pi5, AArch64) and 
 cross-linked with some C libs, and I'm seeing this:

 ```
 2025-08-31T16:22:18.438 [error] extern(C) private ssize_t 
 close(int fd) nothrow
 src/photon/linux/core.d(1150,27):        Previous IR type: i32 
 (i32)
 src/photon/linux/core.d(1150,27):        New IR type:      i64 
 (i32)
 ```

 In linux.core.d: extern(C) private ssize_t close(int fd) nothrow

 but `man 2 close` is `int close(int fd)`, it's a bug?


Yeah it's a bug. I think I've hit it recently and fixed. If I 
fail to produce the next big release in timely manner I'd do a 
hot fix. You might as well add it to issues on Github so we do 
not miss it.
Sep 03
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Sunday, 31 August 2025 at 14:38:27 UTC, Paolo Invernizzi wrote:

 On Monday, 18 August 2025 at 15:20:14 UTC, Dmitry Olshansky


[snip]

 Other photon examples:
 https://github.com/DmitryOlshansky/photon/tree/master


 I tried to include all the sources of photon in a application 
 that it's cross-compiled to linux (Pi5, AArch64) and 
 cross-linked with some C libs, and I'm seeing this:

 ```
 2025-08-31T16:22:18.438 [error] extern(C) private ssize_t 
 close(int fd) nothrow
 src/photon/linux/core.d(1150,27):        Previous IR type: i32 
 (i32)
 src/photon/linux/core.d(1150,27):        New IR type:      i64 
 (i32)
 ```

 In linux.core.d: extern(C) private ssize_t close(int fd) nothrow

 but `man 2 close` is `int close(int fd)`, it's a bug?


Fixed among a ton of other things in v0.14.1.

Introduced Mutex and RecursiveMutex for my upcoming plan to 
rewrite vibe-core on top of photon. Next in line CondVar and with 
that I should be ready to reimplement most of vibe.core.sync.

Also notably I ditched timer based sleeps in favor of a scheduler 
with Mecca's time queue maintained explicitly. Simplified a lot 
of things. I'm uncertain what I'd do about timers so far their 
only API was basically sleep which is already handled by delay. 
That and the coming support for timeout in the select API.

For now it's only Linux and MacOS that have this new scheduler, 
Windows staying mostly as is until around October when I'd 
finally get to my Windows desktop.
Sep 04
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 4 September 2025 at 12:26:26 UTC, Dmitry Olshansky 
wrote:

 On Sunday, 31 August 2025 at 14:38:27 UTC, Paolo Invernizzi 
 wrote:

 [...]


 [snip]

 [...]


 [...]


Great! I'm posting another couple of bugs for macOS on the issue 
tracker.

/P
Sep 05
prev sibling parent reply IchorDev <zxinsworld gmail.com> writes:
On Monday, 18 August 2025 at 15:20:14 UTC, Dmitry Olshansky wrote:

 ```d
 void main() {
     startloop();
     go({
         goOnSameThread({
             writeln("Blocking computation");
             writeln("Integral:", gauss(0.0, 10.0, x => x*x, 
 1e-7));
         });
     });
     runFibers();
 }
 ```


One thing that I think could really be improved about Photon is 
these funny symbol names.
- `startloop` is all-lowercase. It's two words so shouldn't it be 
`startLoop`?
- `go` doesn't actually do any 'go-ing' right away, since fibres 
are deferred; so it's a little misleading. Maybe it could be more 
like `schedule`?
- `goOnSameThread` is hyper-explicit compared to `go`, but its 
name still didn't help me understand it until I read the docs. 
Perhaps `goSync` or `scheduleSync` would be more intuitive?
- `runFiber` is an unfortunate victim of the American-English 
disease. It would be nice to have an alias for 'fibre', which is 
the spelling used in the rest of the English-speaking world.

Would also be great to have a function named something like 'end 
loop' that cleans up everything that the library uses internally 
and allows Photon to be freshly re-initialised with `startloop` 
again later. This would be essential to using Photon in a modular 
environment. If Photon is no longer needed, then we don't want it 
hogging resources until the process dies. Obviously calling such 
a function should not work within a fibre.
Sep 01
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Monday, 1 September 2025 at 10:22:03 UTC, IchorDev wrote:

 On Monday, 18 August 2025 at 15:20:14 UTC, Dmitry Olshansky 
 wrote:

 ```d
 void main() {
     startloop();
     go({
         goOnSameThread({
             writeln("Blocking computation");
             writeln("Integral:", gauss(0.0, 10.0, x => x*x, 
 1e-7));
         });
     });
     runFibers();
 }
 ```


 One thing that I think could really be improved about Photon is 
 these funny symbol names.


The fact those symbols even exist in the first place is because 
the
initial plan was to wrap the D runtime entry point into the 
following:
```d
startloop();
go({
     Dmain(argc, argv);
});
runFibers();
```
But convincing people to try use custom druntime is perishable.

Technically this could still be achieved without hacking Druntime 
a-la:
```d
void main() {
     runPhoton({
        go({...});
     });
```
with runPhoton doing setup and tear down before running the 
closure as the first fiber.



 - `startloop` is all-lowercase. It's two words so shouldn't it 
 be `startLoop`?


It used to start eventloop, now it doesn't so I'd scrap the name 
altogether.


 - `go` doesn't actually do any 'go-ing' right away, since 
 fibres are deferred; so it's a little misleading. Maybe it 
 could be more like `schedule`?


It actually does going right away it's just that "root" fibers 
wait until we start the scheduler. All subsequent fibers are run 
exactly in the style of Go lang.


 - `goOnSameThread` is hyper-explicit compared to `go`, but its 
 name still didn't help me understand it until I read the docs. 
 Perhaps `goSync` or `scheduleSync` would be more intuitive?


Sync what? :) It's a horrible functionality and has a horrible 
name to fit.
go starts fiber on *some* core, goOnSameThread runs on the same 
core that it's called from.


 - `runFiber` is an unfortunate victim of the American-English 
 disease. It would be nice to have an alias for 'fibre', which 
 is the spelling used in the rest of the English-speaking world.


Aliases are just more cognitive load for everybody. runScheduler 
might be better.


 Would also be great to have a function named something like 
 'end loop' that cleans up everything that the library uses 
 internally and allows Photon to be freshly re-initialised with 
 `startloop` again later. This would be essential to using 
 Photon in a modular environment. If Photon is no longer needed, 
 then we don't want it hogging resources until the process dies. 
 Obviously calling such a function should not work within a 
 fibre.


Mostly in unittests. It's something I've been looking into but 
for now I've made startloop idempotent on reinitialization. The 
fact that photon is tied to globals such as file descriptors and 
syscalls on these makes it somewhat less amenable to deinitialize.
Sep 03
parent reply IchorDev <zxinsworld gmail.com> writes:
On Wednesday, 3 September 2025 at 07:32:59 UTC, Dmitry Olshansky 
wrote:

 The fact those symbols even exist in the first place is because 
 the
 initial plan was to wrap the D runtime entry point into the 
 following:
 [...]
 But convincing people to try use custom druntime is perishable.


Indeed. It's like convincing people to use Tango.


 It used to start eventloop, now it doesn't so I'd scrap the 
 name altogether.
 
 It actually does going right away it's just that "root" fibers 
 wait until we start the scheduler. All subsequent fibers are 
 run exactly in the style of Go lang.


Ah, fair enough.


 Sync what? :) It's a horrible functionality and has a horrible 
 name to fit.
 go starts fiber on *some* core, goOnSameThread runs on the same 
 core that it's called from.


'Sync' as in using (the same) one thread. I guess when mixing 
`go` and `goOnSameThread` it could end up being more confusing.
If you want a hideous name idea, I was originally going to 
suggest `scheduleSynchronously`, but I thought it was a bit too 
ugly.


 runScheduler might be better.


Yep, that sounds great!


 Mostly in unittests. It's something I've been looking into but 
 for now I've made startloop idempotent on reinitialization. The 
 fact that photon is tied to globals such as file descriptors 
 and syscalls on these makes it somewhat less amenable to 
 deinitialize.


Hmm... that's difficult then.

Question: is there any way to help Photon recognise blocking 
calls that it doesn't hook into? I ask because (correct me if I'm 
wrong) I don't think Photon hooks into blocking GPU API calls? 
(e.g. in OpenGL, Vulkan, etc.)
Sep 05
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Friday, 5 September 2025 at 16:05:16 UTC, IchorDev wrote:

 Sync what? :) It's a horrible functionality and has a horrible 
 name to fit.
 go starts fiber on *some* core, goOnSameThread runs on the 
 same core that it's called from.


 'Sync' as in using (the same) one thread. I guess when mixing 
 `go` and `goOnSameThread` it could end up being more confusing.
 If you want a hideous name idea, I was originally going to 
 suggest `scheduleSynchronously`, but I thought it was a bit too 
 ugly.


Honestly there is nothing in the way of synchronization it just 
assigns fiber to the thread of calling fiber. Both fibers 
continue operating the way scheduling works, with the only 
advantage that TLS is certainly shared between the two which is 
probably the only reason to use it.


 runScheduler might be better.


 Yep, that sounds great!


Till next version ;) Also need a better name for startloop, I 
guess initPhoton might work.


 Mostly in unittests. It's something I've been looking into but 
 for now I've made startloop idempotent on reinitialization. 
 The fact that photon is tied to globals such as file 
 descriptors and syscalls on these makes it somewhat less 
 amenable to deinitialize.


 Hmm... that's difficult then.


To make it simple I might try to deinitialize after runScheduler. 
So that after all fibers exit we clean up global state, and 
importantly TLS of the main thread that called runScheduler.


 Question: is there any way to help Photon recognise blocking 
 calls that it doesn't hook into? I ask because (correct me if 
 I'm wrong) I don't think Photon hooks into blocking GPU API 
 calls? (e.g. in OpenGL, Vulkan, etc.)


One way is to keep graphics API in its own thread(s) and run 
photon scheduler separately, only the thread calling runScheduler 
and the ones it spawns are affected. Any “foreign” threads just 
pass through syscalls, sychronization between two worlds could be 
done via Events, Semaphores and recently Mutex.

In general Photon intercepts a dozen or so of syscalls, the 
number is expected to go up by offload to threadpool. For now the 
only option is to explicitly use offload explicitly.
Sep 06
prev sibling parent reply GL <gleb.tsk gmail.com> writes:
On Wednesday, 13 August 2025 at 13:28:26 UTC, Dmitry Olshansky 
wrote:


 I need to think a little more about it but I would likely ship 
 it in the next release. Soonish :)


zmq seems to be working, thank you.
Now I'm trying to write a more meaningful piece of code with zmq. 
I'll report on the results.
But about the latest version...

(gdb) run
Starting program: ls589d
Missing separate debuginfo for /lib64/libgcc_s.so.1.
Try to install the hash file 
/usr/lib/debug/.build-id/7d/4235a17cb9325208546a9d570ef4c539578f80.debug
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00005555555fd679 in core.thread.fiber.Fiber.yield() ()

(gdb) bt


_D6photon7reactor__T5delayTS4core4time8DurationZQBcFNbNeQBdZv 
(req=...)
     at .dub/packages/photon/0.14.2/photon/src/photon/reactor.d:368

(this=0x7ffff7b8e060) at source/business/business.d:55


Actual code is:

  void run() {
         goOnSameThread(&runner);

         photon.delay(300.msecs); // <<=== fails here
     }

0.12.2 works well.
Sep 10
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Wednesday, 10 September 2025 at 17:27:26 UTC, GL wrote:

 On Wednesday, 13 August 2025 at 13:28:26 UTC, Dmitry Olshansky 
 wrote:


 [...]


 zmq seems to be working, thank you.
 Now I'm trying to write a more meaningful piece of code with 
 zmq. I'll report on the results.
 But about the latest version...

 [...]


Hm, could you open issue with the full code? It could be a 
problem where I forgot to implement passthrough for threads 
(outside of fibers, ie not from go({})) to just sleep as usual.


 0.12.2 works well.
Sep 12
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Wednesday, 10 September 2025 at 17:27:26 UTC, GL wrote:

 On Wednesday, 13 August 2025 at 13:28:26 UTC, Dmitry Olshansky

  void run() {
         goOnSameThread(&runner);

         photon.delay(300.msecs); // <<=== fails here
     }

 0.12.2 works well.


I have pushed fix for the problem in 0.14.3, try it to see if 
that’s the case.
Sep 15