Photon v0.13.0 with offload

[IchorDev]

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