4 ms·

> >If you start over, there's no reason any blocking API should really BLOCK your program. Your functions can look completely synchronous, but yield to the even

by geocar 6y ago

> >If you start over, there's no reason any blocking API should really BLOCK your program. Your functions can look completely synchronous, but yield to the event loop when they invoke a blocking API. > That implies a level of sophistication and abstraction that simply doesn't exist today, and probably won't for a while. This sounds like a description of UNIX and was true from the very first versions: a blocking call would trap the system, select a process task that can continue and jump to that instead. At the language level, I'm pretty sure we had this in the 1980s in Forth, and I don't think it was considered new even then (although I don't have a reference handy); libdill does this for C programs. Or am I misunderstanding what you're saying?

lmm 6y ago
Multiprocessing (or multithreading, which is the unix model is much the same thing) is even heavier than a green-threading runtime. Instead of swapping out little task handlers / continuations you're swapping out whole address spaces.
simias 6y ago
So there are two things, there's OS-provided event handling (poll, blocking syscall that schedule another task, OS threads) and there's coroutines (libdill and friends). OS-level async is what I accuse some devs to underuse, preferring language-level async constructs. I've read a lot of frankly FUD and cargo culting about how inefficient things like pthreads are. Let's not even talk about pre-fork parallelism which is probably the simplest way to use multiple cores when dealing with independent tasks but hardly anybody seems to use these days. I wonder if most devs even realize that it's an option. In my experience coroutines were never really popular in the C world simply because without GC or at least a borrow checker it's just very hard to write correct code. Avoiding memory violations in C is tricky, avoiding memory violation in async C is asking a lot. Rust does a lot better here thanks to borrow checking but it still leads to, IMO, very complicated code.
- akiselev 6y ago
  > Let's not even talk about pre-fork parallelism which is probably the simplest way to use multiple cores when dealing with independent tasks but hardly anybody seems to use these days. I wonder if most devs even realize that it's an option. Speaking from experience: they don't. I recently picked up a Linux kernel development book [1] and after four or five chapters I was able to eliminate several bottlenecks and eliminate latency edge cases in personal projects with a greater understanding of the scheduler algorithm and process priority/affinity/yields. I think the problem is that the vast majority of developers work on top of cross-platform runtimes that hide any detail that can't be easily implemented for all operating systems. It's been more than a decade since I've used Unix sockets directly in any language and I don't how to set SO_REUSEPORT in Rust. I'd probably have to implement it using `TCPListener::as_raw_fd()` and `unsafe libc::setsockopt`? It's just easier stay sane within the bumpers. [1] https://www.amazon.com/Linux-Kernel-Development-Robert-Love/dp/0672329468/ https://www.amazon.com/Linux-Kernel-Development-Robert-Love/...

by geocar 6y ago

lmm 6y ago

Multiprocessing (or multithreading, which is the unix model is much the same thing) is even heavier than a green-threading runtime. Instead of swapping out little task handlers / continuations you're swapping out whole address spaces.

simias 6y ago

So there are two things, there's OS-provided event handling (poll, blocking syscall that schedule another task, OS threads) and there's coroutines (libdill and friends). OS-level async is what I accuse some devs to underuse, preferring language-level async constructs. I've read a lot of frankly FUD and cargo culting about how inefficient things like pthreads are. Let's not even talk about pre-fork parallelism which is probably the simplest way to use multiple cores when dealing with independent tasks but hardly anybody seems to use these days. I wonder if most devs even realize that it's an option. In my experience coroutines were never really popular in the C world simply because without GC or at least a borrow checker it's just very hard to write correct code. Avoiding memory violations in C is tricky, avoiding memory violation in async C is asking a lot. Rust does a lot better here thanks to borrow checking but it still leads to, IMO, very complicated code.

akiselev 6y ago
> Let's not even talk about pre-fork parallelism which is probably the simplest way to use multiple cores when dealing with independent tasks but hardly anybody seems to use these days. I wonder if most devs even realize that it's an option. Speaking from experience: they don't. I recently picked up a Linux kernel development book [1] and after four or five chapters I was able to eliminate several bottlenecks and eliminate latency edge cases in personal projects with a greater understanding of the scheduler algorithm and process priority/affinity/yields. I think the problem is that the vast majority of developers work on top of cross-platform runtimes that hide any detail that can't be easily implemented for all operating systems. It's been more than a decade since I've used Unix sockets directly in any language and I don't how to set SO_REUSEPORT in Rust. I'd probably have to implement it using `TCPListener::as_raw_fd()` and `unsafe libc::setsockopt`? It's just easier stay sane within the bumpers. [1] https://www.amazon.com/Linux-Kernel-Development-Robert-Love/dp/0672329468/ https://www.amazon.com/Linux-Kernel-Development-Robert-Love/...