3 ms·

"I suppose it depends how you define a "client"." The article defines client as another thread or process - the argument is that these interfaces only support

"I suppose it depends how you define a "client"." The article defines client as another thread or process - the argument is that these interfaces only support two processes and not many. There isn't any functional limit on how many processes can map the same region of memory. "but you're also not mmap()ing all the time, which is what we're actually talking about here" No, I don't think that's at all what we're talking about. We're talking about the ability of the architecture to scale -- not the efficiency of calling one specific syscall. "I was only under the impression you thought the sockets API and mmap() were ideal interfaces." I haven't said that they're ideal, only that they're demonstrably capable of enabling more than just two processes to interact. "and you think that's all basically POSIX anyway, so what's the point?" The point is that the article's conclusion that POSIX is preventing progress is nonsense. As you say, standards emerge. "how much smaller the code would be, and cheaper the hardware (less ram, less rom), and maybe if you can organise the kernel with this model in mind, how much faster it would be." These aren't points raised by the article -- in fact so far we've been discussing the opposite (extensions and features, not cutting features). Could things be cut from POSIX? Sure. But is implementing stuff like select() really a "yoke?" It's not exactly difficult, and I don't think you or anyone has articulated how it might hamper the inclusion of more advanced interfaces. The resources needed to implement POSIX are not significant. What specifically do you think POSIX's architecture is preventing us from implementing?

geocar 4y ago
> The article defines client as another thread or process It does no such thing. The word "client" is given once in the text, and little is said except it isn't a thread due to the fact their support is fraught with peril and often poorly provided for by programming languages > I haven't said that they're ideal, only that they're demonstrably capable of enabling more than just two processes to interact. So was carrier pigeon, but sometimes we want to send messages faster than that. > These aren't points raised by the article -- in fact so far we've been discussing the opposite (extensions and features, not cutting features). >... about the ability of the architecture to scale -- not the efficiency of calling one specific syscall. > What specifically do you think POSIX's architecture is preventing us from implementing? Erm, they are the points raised by the article, that's kind-of why I think you still haven't read it yet. Here's the paragraph right after the one where it defines a client as not-a-thread (and after talking about one specific syscall): The death of any of these systems is when a user asks, "What about Posix? How can I port my XXX program to run on your system?" Providing Posix-like semantics in these systems is their death knell, because the Posix way of thinking is so narrow and providing its varied illusions requires so many hidden changes and adherences to age-old assumptions that there is no way to have a flexible innovative system and serve the Posix elephant. This means that no matter how innovative and clever a system is, once it is tainted by Posix support, it becomes just another Posix system. > But is implementing stuff like select() really a "yoke?" It's not exactly difficult, and I don't think you or anyone has articulated how it might hamper the inclusion of more advanced interfaces Could you show me? I don't think it's possible to implement a select() that works with Linux's fancy new iouring that uses the provided files and buffers features easily, but I'd like to be proven wrong.
- throwaway09223 4y ago
  "It does no such thing." It does. It says quite clearly, quote "If you look at most inter-process communication mechanisms, you can see that they are most often used by only two programs — usually a client and server." Two processes on a local machine, using shared memory or other IPC. IPC, not network calls. "So was carrier pigeon, but sometimes we want to send messages faster than that." Don't be disingenuous. You haven't articulated a faster mechanism and in fact there isn't one. "Erm, they are the points raised by the article," No, they are not. Based on your replies it seems you may fundamentally not understand the points raised by the article. "Could you show me? I don't think it's possible to implement a select() that works with Linux's fancy new iouring that uses the provided files and buffers features easily, but I'd like to be proven wrong." You've already provided an example. The Linux kernel provides both select, a posix interface, and io_uring. Nothing about providing posix interfaces precludes providing specialized interfaces as well.
  - geocar 4y ago
    > It says quite clearly, quote "If you look at most inter-process communication mechanisms, you can see that they are most often used by only two programs — usually a client and server." Two processes on a local machine, using shared memory or other IPC. IPC, not network calls. Two processes! Not two threads! > Don't be disingenuous. How would you know? You still haven't read the article, so you're arguing with a straw-man! > You haven't articulated a faster mechanism and in fact there isn't one. "la la la my fingers are in my ears I can't hear you!" is the best you got? You seem to admit iouring exists, isn't POSIX, but what? You just don't believe it's faster now? Bull shit. > You've already provided an example. The Linux kernel provides both select, a posix interface, and io_uring. Nothing about providing posix interfaces precludes providing specialized interfaces as well. If you think a reimplementation of Linux is "easy" you need to have your head examined: Microsoft has near-infinite money and eventually gave up, deciding POSIX was too hard, and just implemented another hypervisor.
    - throwaway09223 4y ago
      "Two processes! Not two threads!" And I wrote "thread or process" because, architecturally regarding IPC, the distinction is unimportant. "How would you know?" Due to the inaccuracy of your analogy, with regard to actual systems interfaces. "You seem to admit iouring exists, isn't POSIX, but what? You just don't believe it's faster now? Bull shit." io_uring is not faster than shared memory via mmap. "If you think a reimplementation of Linux is "easy" you need to have your head examined" I think now we're touching on the limits of your experience and expertise. Implementing select(2) on Linux is indeed quite simple. Have you ever read through select.c? Have you ever even implemented a posix subsystem? I have. "Microsoft has near-infinite money and eventually gave up, deciding POSIX was too hard, and just implemented another hypervisor. " This isn't how things work on Windows. As an aside, I've noticed that your ignorance has shifted into rudeness. Don't bother to respond again. This conversation is over.

geocar 4y ago

> The article defines client as another thread or process It does no such thing. The word "client" is given once in the text, and little is said except it isn't a thread due to the fact their support is fraught with peril and often poorly provided for by programming languages > I haven't said that they're ideal, only that they're demonstrably capable of enabling more than just two processes to interact. So was carrier pigeon, but sometimes we want to send messages faster than that. > These aren't points raised by the article -- in fact so far we've been discussing the opposite (extensions and features, not cutting features). >... about the ability of the architecture to scale -- not the efficiency of calling one specific syscall. > What specifically do you think POSIX's architecture is preventing us from implementing? Erm, they are the points raised by the article, that's kind-of why I think you still haven't read it yet. Here's the paragraph right after the one where it defines a client as not-a-thread (and after talking about one specific syscall): The death of any of these systems is when a user asks, "What about Posix? How can I port my XXX program to run on your system?" Providing Posix-like semantics in these systems is their death knell, because the Posix way of thinking is so narrow and providing its varied illusions requires so many hidden changes and adherences to age-old assumptions that there is no way to have a flexible innovative system and serve the Posix elephant. This means that no matter how innovative and clever a system is, once it is tainted by Posix support, it becomes just another Posix system. > But is implementing stuff like select() really a "yoke?" It's not exactly difficult, and I don't think you or anyone has articulated how it might hamper the inclusion of more advanced interfaces Could you show me? I don't think it's possible to implement a select() that works with Linux's fancy new iouring that uses the provided files and buffers features easily, but I'd like to be proven wrong.

throwaway09223 4y ago
"It does no such thing." It does. It says quite clearly, quote "If you look at most inter-process communication mechanisms, you can see that they are most often used by only two programs — usually a client and server." Two processes on a local machine, using shared memory or other IPC. IPC, not network calls. "So was carrier pigeon, but sometimes we want to send messages faster than that." Don't be disingenuous. You haven't articulated a faster mechanism and in fact there isn't one. "Erm, they are the points raised by the article," No, they are not. Based on your replies it seems you may fundamentally not understand the points raised by the article. "Could you show me? I don't think it's possible to implement a select() that works with Linux's fancy new iouring that uses the provided files and buffers features easily, but I'd like to be proven wrong." You've already provided an example. The Linux kernel provides both select, a posix interface, and io_uring. Nothing about providing posix interfaces precludes providing specialized interfaces as well.
- geocar 4y ago
  > It says quite clearly, quote "If you look at most inter-process communication mechanisms, you can see that they are most often used by only two programs — usually a client and server." Two processes on a local machine, using shared memory or other IPC. IPC, not network calls. Two processes! Not two threads! > Don't be disingenuous. How would you know? You still haven't read the article, so you're arguing with a straw-man! > You haven't articulated a faster mechanism and in fact there isn't one. "la la la my fingers are in my ears I can't hear you!" is the best you got? You seem to admit iouring exists, isn't POSIX, but what? You just don't believe it's faster now? Bull shit. > You've already provided an example. The Linux kernel provides both select, a posix interface, and io_uring. Nothing about providing posix interfaces precludes providing specialized interfaces as well. If you think a reimplementation of Linux is "easy" you need to have your head examined: Microsoft has near-infinite money and eventually gave up, deciding POSIX was too hard, and just implemented another hypervisor.
  - throwaway09223 4y ago
    "Two processes! Not two threads!" And I wrote "thread or process" because, architecturally regarding IPC, the distinction is unimportant. "How would you know?" Due to the inaccuracy of your analogy, with regard to actual systems interfaces. "You seem to admit iouring exists, isn't POSIX, but what? You just don't believe it's faster now? Bull shit." io_uring is not faster than shared memory via mmap. "If you think a reimplementation of Linux is "easy" you need to have your head examined" I think now we're touching on the limits of your experience and expertise. Implementing select(2) on Linux is indeed quite simple. Have you ever read through select.c? Have you ever even implemented a posix subsystem? I have. "Microsoft has near-infinite money and eventually gave up, deciding POSIX was too hard, and just implemented another hypervisor. " This isn't how things work on Windows. As an aside, I've noticed that your ignorance has shifted into rudeness. Don't bother to respond again. This conversation is over.