Photon v0.14.1 with Mecca's reactor time queue (page 3)

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

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

September 06

Re: Photon v0.13.0 with offload

Posted by Dmitry Olshansky
in reply to IchorDev

Permalink

Dmitry Olshansky

Posted in reply to IchorDev

Permalink

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.

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.

> >

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.

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.

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 #0 0x00005555555fd679 in core.thread.fiber.Fiber.yield() () #1 0x00005555555842d5 in _D6photon7reactor__T5delayTS4core4time8DurationZQBcFNbNeQBdZv (req=...) at .dub/packages/photon/0.14.2/photon/src/photon/reactor.d:368 #2 0x000055555558adb7 in _D8businessQj8Business3runMFZv (this=0x7ffff7b8e060) at source/business/business.d:55 #3 0x000055555558be9a in _Dmain () at source/app.d:54 Actual code is: void run() { goOnSameThread(&runner); photon.delay(300.msecs); // <<=== fails here } 0.12.2 works well.

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.

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.

Forums