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.
