Photon v0.13.0 with offload

[Dmitry Olshansky]

On Monday, 1 September 2025 at 10:22:03 UTC, IchorDev wrote:
> On Monday, 18 August 2025 at 15:20:14 UTC, Dmitry Olshansky 
> wrote:
>> ```d
>> void main() {
>>     startloop();
>>     go({
>>         goOnSameThread({
>>             writeln("Blocking computation");
>>             writeln("Integral:", gauss(0.0, 10.0, x => x*x, 
>> 1e-7));
>>         });
>>     });
>>     runFibers();
>> }
>> ```
>
> One thing that I think could really be improved about Photon is 
> these funny symbol names.

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:
```d
startloop();
go({
     Dmain(argc, argv);
});
runFibers();
```
But convincing people to try use custom druntime is perishable.

Technically this could still be achieved without hacking Druntime 
a-la:
```d
void main() {
     runPhoton({
        go({...});
     });
```
with runPhoton doing setup and tear down before running the 
closure as the first fiber.


> - `startloop` is all-lowercase. It's two words so shouldn't it 
> be `startLoop`?

It used to start eventloop, now it doesn't so I'd scrap the name 
altogether.

> - `go` doesn't actually do any 'go-ing' right away, since 
> fibres are deferred; so it's a little misleading. Maybe it 
> could be more like `schedule`?

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.

> - `goOnSameThread` is hyper-explicit compared to `go`, but its 
> name still didn't help me understand it until I read the docs. 
> Perhaps `goSync` or `scheduleSync` would be more intuitive?

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.

> - `runFiber` is an unfortunate victim of the American-English 
> disease. It would be nice to have an alias for 'fibre', which 
> is the spelling used in the rest of the English-speaking world.

Aliases are just more cognitive load for everybody. runScheduler 
might be better.

> Would also be great to have a function named something like 
> 'end loop' that cleans up everything that the library uses 
> internally and allows Photon to be freshly re-initialised with 
> `startloop` again later. This would be essential to using 
> Photon in a modular environment. If Photon is no longer needed, 
> then we don't want it hogging resources until the process dies. 
> Obviously calling such a function should not work within a 
> fibre.

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.