Timeline for Why is it necessary for every new api to be async?
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 17, 2019 at 18:30 | comment | added | Sebastian Redl | The socket APIs have async methods, and those use Windows overlapped I/O, not the old WSAPI primitives. In .Net Core anyway. | |
| Aug 17, 2019 at 18:20 | comment | added | Theraot |
@SebastianRedl about .NET, looking with Just Decompile, I see HttpClientHandler.SendAsync uses Task.Run. About .NET Core, I find it uses a WinHttpHandler that uses TaskFactory.StartNew. Could they not do it without spinning a thread?
|
|
| Aug 17, 2019 at 18:14 | comment | added | Theraot |
@SebastianRedl I found recv, the docs says "f no incoming data is available at the socket, the recv call blocks and waits for data to arrive according to the blocking rules defined for WSARecv with the MSG_PARTIAL flag not set unless the socket is nonblocking." and about MSG_PARTIAL I find "Be aware that the MSG_PARTIAL flag bit is not supported by all protocols."
|
|
| Aug 17, 2019 at 17:54 | comment | added | Sebastian Redl | "Although some API do actually need to block on a Thread – and I think that is the case for listening on a socket, at least on Windows" - No, listening on sockets is truly asynchronous. | |
| Aug 17, 2019 at 4:54 | history | edited | Theraot | CC BY-SA 4.0 |
added 36 characters in body
|
| Aug 17, 2019 at 4:45 | history | edited | Theraot | CC BY-SA 4.0 |
added 335 characters in body
|
| Aug 17, 2019 at 4:31 | history | answered | Theraot | CC BY-SA 4.0 |