Photon v0.13.0 with offload

Dmitry Olshansky dmitry.olsh at gmail.com
Sat Sep 6 17:03:00 UTC 2025


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.





More information about the Digitalmars-d-announce mailing list