Am 21.04.2024 um 21:01 schrieb Dmitry Olshansky:
> Photon is a minimalistic multi-threaded fiber scheduler and event loop that works transparently with traditional blocking I/O C/C++/D/Rust libraries w/o degrading performance.
> 
> It took somewhat longer than I wanted but I'm pleased to announce that Photon now supports Windows. In particular basic socket API that is used by the likes of std.socket is transparently converted to overlapped I/O with I/O completion port event loop. The last obstacle was, of course, accept syscall that is only blocking on Windows. Now that transparently goes to a dedicated Windows's native threadpool so as to not block our precious fibers.
> 
> Explore some basic examples here (not all examples can be run on Windows): https://github.com/DmitryOlshansky/photon/tree/master/tests
> 
> -- 
> Dmitry Olshansky
> CEO @ Glowlabs
> https://olshansky.me

That's really nice! How would you judge supporting other kinds of handles, such as files or events, on Windows?

I guess that the Darwin support will be restricted to freely distributed macOS applications, as calling `__syscall` surely is a private API that cannot be used in any AppStore application, right? In that case it would inevitably put it in a non-consumer application niche, but certainly wouldn't make it any less interesting for more server oriented tasks.

On Tuesday, 23 April 2024 at 17:15:13 UTC, Sönke Ludwig wrote:
> Am 21.04.2024 um 21:01 schrieb Dmitry Olshansky:
>> Photon is a minimalistic multi-threaded fiber scheduler and event loop that works transparently with traditional blocking I/O C/C++/D/Rust libraries w/o degrading performance.
>> 
>> It took somewhat longer than I wanted but I'm pleased to announce that Photon now supports Windows. In particular basic socket API that is used by the likes of std.socket is transparently converted to overlapped I/O with I/O completion port event loop. The last obstacle was, of course, accept syscall that is only blocking on Windows. Now that transparently goes to a dedicated Windows's native threadpool so as to not block our precious fibers.
>> 
>> Explore some basic examples here (not all examples can be run on Windows): https://github.com/DmitryOlshansky/photon/tree/master/tests
>> 
>> --
>> Dmitry Olshansky
>> CEO @ Glowlabs
>> https://olshansky.me
>
> That's really nice! How would you judge supporting other kinds of handles, such as files or events, on Windows?

Going to be tricky but timers for one thing should work with the threadpool I got in there.

> I guess that the Darwin support will be restricted to freely distributed macOS applications, as calling `__syscall` surely is a private API that cannot be used in any AppStore application, right?

You tell me;)
API looks just like any other libc function.

> In that case it would inevitably put it in a non-consumer application niche, but certainly wouldn't make it any less interesting for more server oriented tasks.

My main angle is being able to develop servers / clients on MacOS deploying to other platforms such as Linux server.

—
Dmitry Olshansky
CEO @ Glowlabs
https://olshansky.me

On 25/04/2024 5:41 AM, Dmitry Olshansky wrote:
> On Wednesday, 24 April 2024 at 14:40:40 UTC, Steven Schveighoffer wrote:
>> On Tuesday, 23 April 2024 at 19:05:48 UTC, Dmitry Olshansky wrote:
>>> On Tuesday, 23 April 2024 at 17:15:13 UTC, Sönke Ludwig wrote:
>>>> I guess that the Darwin support will be restricted to freely distributed macOS applications, as calling `__syscall` surely is a private API that cannot be used in any AppStore application, right?
>>>
>>> You tell me;)
>>> API looks just like any other libc function.
>>
>> I can tell you right off that this will not be allowed in approved apps. Not just for the `__syscall`, but for overriding the normal system calls of all libraries. I can't imagine Apple will be OK with that.
> 
> How would they know? The whole thing happens at the link time.
> 
> —
> Dmitry Olshansky
> CEO @ Glowlabs
> https://olshansky.me

Two ways:

Look at externs for your binaries, if any symbol is black listed, it won't be allowed (such as ``__syscall``).

Decompile, if you see certain instructions, don't allow it.

I can't find it, but we did have something in druntime that was failing due to private API usage in the past (and hence couldn't publish D applications).