digitalmars.D - Phobos v2 asynchronous IO
- IGotD- (8/8) Apr 16 2022 Is there any planning or work to move Phobos towards natively
- Adam D Ruppe (5/8) Apr 16 2022 Windows 95 included native asynchronous I/O (and it is quite
- Tobias Pankrath (3/11) Apr 16 2022 You have a pointer to the Windows API you mention? Do you mean
- Adam D Ruppe (2/4) Apr 16 2022 Yes. WriteFileEx and associated things.
- a11e99z (2/7) Apr 16 2022 https://docs.microsoft.com/en-us/troubleshoot/windows/win32/asynchronous...
- Adam Ruppe (14/22) Apr 16 2022 If your point is that the Windows API is both easy to use and
- Suliman (2/10) Apr 18 2022 Could you give link to read more about it?
- SealabJaster (15/19) Apr 16 2022 I'd love it if we finally had a way forward on a proper, standard
- IGotD- (5/7) Apr 16 2022 Yes, that's why I bring this up because creating a good asych API
- rikki cattermole (6/15) Apr 16 2022 This shouldn't be done in Phobos. It can be done right now separately.
- Paul Backus (3/12) Apr 16 2022 Why wait for Phobos to get its act together? Put it up on dub and
- IGotD- (5/7) Apr 16 2022 Because it should be an official async Phobos interface that
- Paul Backus (15/24) Apr 16 2022 A library can be "official" and "first party" without being part
Is there any planning or work to move Phobos towards natively asynchronous IO? Right now most IO is synchronous like you would expect from an API from the 90s. Time has moved on asynchronous IO should be standard. This means that everything should be asynchronous, file streams, networking, anything that streams as standard. If this is implemented then we also can look into adding native asynchronous
Apr 16 2022
On Saturday, 16 April 2022 at 10:19:22 UTC, IGotD- wrote:Is there any planning or work to move Phobos towards natively asynchronous IO? Right now most IO is synchronous like you would expect from an API from the 90s.Windows 95 included native asynchronous I/O (and it is quite pleasant to use, this is probably what the api should be based on). These things aren't as new as you think lol But I don't think there's any plans for Phobos at all.
Apr 16 2022
On Saturday, 16 April 2022 at 13:08:51 UTC, Adam D Ruppe wrote:On Saturday, 16 April 2022 at 10:19:22 UTC, IGotD- wrote:You have a pointer to the Windows API you mention? Do you mean overlapped io?Is there any planning or work to move Phobos towards natively asynchronous IO? Right now most IO is synchronous like you would expect from an API from the 90s.Windows 95 included native asynchronous I/O (and it is quite pleasant to use, this is probably what the api should be based on). These things aren't as new as you think lol But I don't think there's any plans for Phobos at all.
Apr 16 2022
On Saturday, 16 April 2022 at 17:17:57 UTC, Tobias Pankrath wrote:You have a pointer to the Windows API you mention? Do you mean overlapped io?Yes. WriteFileEx and associated things.
Apr 16 2022
On Saturday, 16 April 2022 at 17:29:41 UTC, Adam D Ruppe wrote:On Saturday, 16 April 2022 at 17:17:57 UTC, Tobias Pankrath wrote:https://docs.microsoft.com/en-us/troubleshoot/windows/win32/asynchronous-disk-io-synchronous#asynchronous-io-still-appears-to-be-synchronousYou have a pointer to the Windows API you mention? Do you mean overlapped io?Yes. WriteFileEx and associated things.
Apr 16 2022
Adam Ruppe <destructionator gmail.com> On Saturday, 16 April 2022 at 19:33:16 UTC, a11e99z wrote:On Saturday, 16 April 2022 at 17:29:41 UTC, Adam D Ruppe wrote:If your point is that the Windows API is both easy to use and performs well for the majority of cases, I agree. When data is issued from a cache, it is faster to just issue the answer and saves you from an allocation down the line since you can keep the buffer in the pool. Of course, there are some cases where you need to do extra tuning, but the api makes it possible. Maybe in theory we could invent something better, but for one, it is going to need to be built on what the operating system provides anyway, and really, when it comes to api design, you're often in good shape copying something that is widely used in the real world - even if it is less than perfect, at least its quirks are well documented.On Saturday, 16 April 2022 at 17:17:57 UTC, Tobias Pankrath wrote:https://docs.microsoft.com/en-us/troubleshoot/windows/win32/asynchronous-disk-io-synchronous#asynchronous-io-still-appears-to-be-synchronousYou have a pointer to the Windows API you mention? Do you mean overlapped io?Yes. WriteFileEx and associated things.
Apr 16 2022
On Saturday, 16 April 2022 at 13:08:51 UTC, Adam D Ruppe wrote:On Saturday, 16 April 2022 at 10:19:22 UTC, IGotD- wrote:Could you give link to read more about it?Is there any planning or work to move Phobos towards natively asynchronous IO? Right now most IO is synchronous like you would expect from an API from the 90s.Windows 95 included native asynchronous I/O (and it is quite pleasant to use, this is probably what the api should be based on). These things aren't as new as you think lol But I don't think there's any plans for Phobos at all.
Apr 18 2022
On Saturday, 16 April 2022 at 10:19:22 UTC, IGotD- wrote:This means that everything should be asynchronous, file streams, networking, anything that streams as standard. If this is implemented then we also can look into adding nativeI'd love it if we finally had a way forward on a proper, standard async framework to build off of. However I can already see the endless bickering about extremely tiny details that people present as show stoppers (and of course the `but muh -betterC nogc nothrow pure const auto ref shared` debate). So maybe in 10 years once D decides to catch up with modern application development we might have a proposal ;) Also, we couldn't even get something 'simple' like string interpolation into the language, so I have literally negative hope of native async/await being brought in. (As much as it sounds like I'm bashing the language, it's still my favourite, and I bring it up way too much to my work colleagues)
Apr 16 2022
On Saturday, 16 April 2022 at 13:41:17 UTC, SealabJaster wrote:So maybe in 10 years once D decides to catch up with modern application development we might have a proposal ;)Yes, that's why I bring this up because creating a good asych API is very difficult. That's why we should use Phobos v2 to play around with different solutions and hopefully it will converge into something good.
Apr 16 2022
On 17/04/2022 4:17 AM, IGotD- wrote:On Saturday, 16 April 2022 at 13:41:17 UTC, SealabJaster wrote:This shouldn't be done in Phobos. It can be done right now separately. There is a lot of components to this, event loop, file handling, socket handling, thread handling, queues, timers, future. The actual async/await type primitives are just syntax suger around that. Its all on my todo list, but ya know, big list.So maybe in 10 years once D decides to catch up with modern application development we might have a proposal ;)Yes, that's why I bring this up because creating a good asych API is very difficult. That's why we should use Phobos v2 to play around with different solutions and hopefully it will converge into something good.
Apr 16 2022
On Saturday, 16 April 2022 at 16:17:23 UTC, IGotD- wrote:On Saturday, 16 April 2022 at 13:41:17 UTC, SealabJaster wrote:Why wait for Phobos to get its act together? Put it up on dub and we can start playing around today.So maybe in 10 years once D decides to catch up with modern application development we might have a proposal ;)Yes, that's why I bring this up because creating a good asych API is very difficult. That's why we should use Phobos v2 to play around with different solutions and hopefully it will converge into something good.
Apr 16 2022
On Saturday, 16 April 2022 at 16:25:16 UTC, Paul Backus wrote:Why wait for Phobos to get its act together? Put it up on dub and we can start playing around today.Because it should be an official async Phobos interface that other libraries can use. There already exist async libraries which are half done and maintained. Also you shouldn't be forced to pull some third party library for basic IO functionality.
Apr 16 2022
On Saturday, 16 April 2022 at 19:20:25 UTC, IGotD- wrote:On Saturday, 16 April 2022 at 16:25:16 UTC, Paul Backus wrote:A library can be "official" and "first party" without being part of Phobos. For example, it could be owned by the [Github dlang organization][1], and have its documentation hosted on dlang.org alongside the official standard library docs. There are substantial advantages to putting a library on dub rather than in Phobos, including the ability to release breaking changes using semantic versioning, and the ability to release updates independently of Phobos's release schedule. As far as "half done and maintained" goes...the people writing and maintaining libraries on dub and the people writing and maintaining Phobos modules are, for the most part, the same people. If they couldn't do a good enough job to satisfy you on dub, what makes you think they'll do a better job in Phobos? [1]: https://github.com/dlang/Why wait for Phobos to get its act together? Put it up on dub and we can start playing around today.Because it should be an official async Phobos interface that other libraries can use. There already exist async libraries which are half done and maintained. Also you shouldn't be forced to pull some third party library for basic IO functionality.
Apr 16 2022