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