Repository navigation
v4.0 #557
Description
We introduce breaking changes in network 4.0. Windows support moves to WinIO only; v3.2 remains the line for No IO Manager on Windows and for older GHCs.
- Specifying
StrictandStrictDatato avoid space leak (Using strict language extension #412) - Integrating with the new Windows IO manager (Integrate with the new Windows IO manager #364), and dropping No IO Manager support on Windows; the plan is in Supporting WinIO in the same shape as POSIX (network 4.0) #642
- Basic WinIO support (WinIO work #612, winio: load the msg extension functions from Haskell, and fix a spurious EOF #626, WinIO: skip the completion port when a socket request finishes at once #639)
- Readiness (
waitReadSocketSTMand friends) throughIOCTL_AFD_POLL(Wait for readiness on Windows through IOCTL_AFD_POLL under WinIO #641) - The give-up API on WinIO, and removing the No IO Manager code (WinIO the POSIX way: non-blocking sockets, readiness-based give-ups #643, Windows needs WinIO: remove the No IO Manager code #644)
- A clear error when started with No IO Manager on Windows (Windows needs WinIO: remove the No IO Manager code #644)
- Correcting socket type on Windows (Socket type is incorrect on Windows #426, Make CSocket as wide as SOCKET on Windows #646)
- Correcting address argument in
recvfrom()(Incorrect handling ofaddressargument in recvfrom() #539) - Supporting GHC 9.x only (Support GHC 9.4 or later only #645)
- POSIX: GHC 9.4 or later, as CI tests
- Windows: GHC with
__IO_MANAGER_WINIO__ >= 2(9.12.5 or later in 9.12, 9.14.2 or later) - Raising
base, updatingtested-with, and removing CPP for older GHCs
@Mistuke It's time!
Reacted by coot
Activity
coot commentedon Jul 3, 2023
@kazu-yamamoto do you want us to help with it? I won't have time right now, but I might get some help from our partners (Galois).
kazu-yamamoto commentedon Jul 4, 2023
@coot I'd love to help you. But as talked in #559, the baton was passed to @Mistuke now.
When he show me the first example, I can hack the entire package.
Mistuke commentedon Jul 17, 2023
kazu-yamamoto commentedon Mar 26, 2024
Supporting WinIO is delayed.
I would like to set the target version to v4.0.
I will use v3.2 for other purposes.
[-]v3.2[/-][+]v4.0[/+]TravisWhitaker commentedon Mar 19, 2025
I'm curious about whether or not the public interface needs to change in order to support WinIO. My understanding is that
IOPortis roughly analogous to what's achieved withthreadWait*in the current implementation: request the IO and the block the Haskell thread until it's completed.In general it seems desirable to maintain the pattern that GHC users currently employ:
forkIOas many threads as you need, let them block when they need to, and let the IO manager handle the rest. The absence of Rust/Swift/etc. asynchronous callback style APIs is one of big advantages of Haskell's concurrency model.kazu-yamamoto commentedon Mar 20, 2025
Good point. We don't bump major version if not necessary.
TravisWhitaker commentedon Mar 20, 2025
Well, whether or not to bump the major version is one question, and whether or not to move to a callback-based async style API in this package is another entirely.
Mistuke commentedon Mar 20, 2025
To get Winio to work doesn't need an API change. To get the most out of it will eventually. If RIO is to ever be implemented the DMA interface needs to be exposed to users. For instance a single haskell thread can easily handle multiple io requests.
TravisWhitaker commentedon Mar 20, 2025
What would it look like for a single Haskell green thread to handle multiple concurrent requests?
ver bumps up to 4.0.0.0 [skip ci]
kazu-yamamoto commentedon Nov 14, 2026
I will resume this task with LLM.