digitalmars.D.announce - photon v0.7.0 with Windows support(!)
- Dmitry Olshansky (18/18) Apr 21 Photon is a minimalistic multi-threaded fiber scheduler and event
- Dmitry Olshansky (7/25) Apr 21 It gets better, now with hotfixed HTTP hello world example:
- Dmitry Olshansky (3/12) Apr 21 Messed things up with hotfix leaving debug tracing enabled even
- =?UTF-8?Q?S=C3=B6nke_Ludwig?= (8/27) Apr 23 That's really nice! How would you judge supporting other kinds of
- Dmitry Olshansky (11/42) Apr 23 Going to be tricky but timers for one thing should work with the
- Steven Schveighoffer (6/13) Apr 24 I can tell you right off that this will not be allowed in
- Dmitry Olshansky (7/21) Apr 24 How would they know? The whole thing happens at the link time.
- Richard (Rikki) Andrew Cattermole (8/29) Apr 24 Two ways:
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
Apr 21
On Sunday, 21 April 2024 at 19:01:04 UTC, Dmitry Olshansky wrote: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.meIt gets better, now with hotfixed HTTP hello world example: https://github.com/DmitryOlshansky/photon/blob/master/bench/static_http/hello.d -- Dmitry Olshansky CEO GLowlabs https://olshansky.me
Apr 21
Dmitry Olshansky <dmitry.olsh gmail.com> On Sunday, 21 April 2024 at 19:32:20 UTC, Dmitry Olshansky wrote:On Sunday, 21 April 2024 at 19:01:04 UTC, Dmitry Olshansky wrote:Messed things up with hotfix leaving debug tracing enabled even in production builds, please use v0.7.2.[...]It gets better, now with hotfixed HTTP hello world example: https://github.com/DmitryOlshansky/photon/blob/master/bench/static_http/hello.d-- Dmitry Olshansky CEO GLowlabs https://olshansky.me
Apr 21
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.meThat'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.
Apr 23
On Tuesday, 23 April 2024 at 17:15:13 UTC, Sönke Ludwig wrote:Am 21.04.2024 um 21:01 schrieb Dmitry Olshansky:Going to be tricky but timers for one thing should work with the threadpool I got in there.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.meThat'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?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
Apr 23
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 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. -SteveI 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.
Apr 24
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:How would they know? The whole thing happens at the link time. — Dmitry Olshansky CEO Glowlabs https://olshansky.meOn Tuesday, 23 April 2024 at 17:15:13 UTC, Sönke Ludwig wrote: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.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.
Apr 24
On 25/04/2024 5:41 AM, Dmitry Olshansky wrote:On Wednesday, 24 April 2024 at 14:40:40 UTC, Steven Schveighoffer wrote: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).On Tuesday, 23 April 2024 at 19:05:48 UTC, Dmitry Olshansky wrote:How would they know? The whole thing happens at the link time. — Dmitry Olshansky CEO Glowlabs https://olshansky.meOn Tuesday, 23 April 2024 at 17:15:13 UTC, Sönke Ludwig wrote: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.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.
Apr 24