Bus1: a new Linux interprocess communication proposal • Hacker News Board

Re: Bus1: a new Linux interprocess communication proposal

#131

Post by saynsedit » Sat, Aug 20, 2016, 6:31 PM UTC

tomegun wrote: post #129

saynsedit wrote: post #127

Earlier quoted context omitted.

* I don't see a time-slice accounting for the bus broker as an issue. If it's a system daemon, you can define away the problem. What's the use case for doing time-slice accounting where ignoring the system daemon's usage matters? * for priority inheritance, have multiple daemons for each message priority level. Only privileges processes can use the high-priority message router, but can optionally use the low-priority…

I don't get what you are trying to achieve with this discussion. You didn't provide any serious alternative, you just say that the issues don't matter to you. Obviously, if you do not care about any of the features, then you should not be using bus1. But that does not mean that others don't care, so why are you objecting so strongly to us providing a solution to these problems? Firstly, if you don't want a bus IPC wi…

The original point is that this doesn't have to be a kernel. None of the current rationale gives any use-cases for the features you're offering, you're just saying "this feature requires kernel support" well what is the use case for that feature? Maybe there is another way that doesn't require kernel support.

Multicast messaging as your main motivation for a message ordering layer when that layer has drastic effects on performance and operational characteristics is a strange proposition. I'm willing to argue that 99% of application protocols will have no use for baked-in multicast as you've implemented it. What exactly is the killer use case for multicast messaging with side-channel aware causal message ordering? What prevents an application that cares about this from ordering incoming messages according to a lamport clock itself?

I see no downside to these features in general, it's just that the justification for putting it in the kernel is weak. Kernel code has an infinitely high maintenance cost and it's not clear bus1 is the end-all messaging layer you want it to be. There are lots of past failed examples, inotify, dnotify, and fanotify come to mind...

Re: Bus1: a new Linux interprocess communication proposal

#132

Post by Annatar » Sun, Aug 21, 2016, 12:18 PM UTC

qwertyuiop924 wrote: post #130

Annatar wrote: post #128

Earlier quoted context omitted.

And I'd love to avoid putting another layer between the games and the hardware if I have to. I remember using Wine. I agree, that makes perfect sense. and in any case I doubt they're good enough to get the games talking to my GPU properly. Now that's a whole different story: NVIDIA provides Solaris-native packages for their drivers, and they JustWork(SM). Way back in the day, NVIDIA engineers were stunned that they d…

I was really concerned with a) driver perf, and b) how the drivers worked in an LX-branded zone. Steam and the Humble Bundle will leave me set for games. And now, because you didn't ask for it, Game Reccomendations: Have you tried out TIS-100? You can get it through Steam, and maybe a few other places, it runs on Mac, and I'm willing to bet it'll run in an LX-brand. It bills itself as "the assembly language puzzler n…

I didn't ask for it, but I love the clues you drop... "TIS-100"? "Xonotic"? My interest is further piqued, now I have to go and research...

Apropos Qt, it is not for the faint of heart: even on platforms it officially supports, it is very hard to build, at least it was last I had to do it professionally, back in 2013. Qt is really unprofessional as a product, I remember it involved a lot of hacking and coercion of the build engine to get it to build. And it's monstrously large.

Post scriptum:

ah, "Xonotic" is a fork of "Nexuiz". Okay, that's clear now. "TIS-100" is a puzzle game. So these are individual titles, not technology which enables running on a different operating system. "The Ur-Quan Masters" used to build and run superbly on Solaris; it showcased just how good of a gaming platform Solaris could be if the code is good and clean.

lx-brand could be made to work, this screenshot shows it's possible:

https://www.perkin.org.uk/posts/whats-new-in-pkgsrc-2013Q2.h...

I haven't researched how to translate that into the lx-branded zone though (what the package equivalents would be), primarily because I viewed even the above as too much work: for example, the desktop would have to be brought over to somewhere with an X server. I don't see how it could be made to start on the bare metal's display when it's running in one of the hypervisor's zones?

Re: Bus1: a new Linux interprocess communication proposal

#133

Post by qwertyuiop924 » Sun, Aug 21, 2016, 6:04 PM UTC

Annatar wrote: post #132

qwertyuiop924 wrote: post #130

Earlier quoted context omitted.

I was really concerned with a) driver perf, and b) how the drivers worked in an LX-branded zone. Steam and the Humble Bundle will leave me set for games. And now, because you didn't ask for it, Game Reccomendations: Have you tried out TIS-100? You can get it through Steam, and maybe a few other places, it runs on Mac, and I'm willing to bet it'll run in an LX-brand. It bills itself as "the assembly language puzzler n…

I didn't ask for it, but I love the clues you drop... "TIS-100"? "Xonotic"? My interest is further piqued, now I have to go and research... Apropos Qt, it is not for the faint of heart: even on platforms it officially supports, it is very hard to build, at least it was last I had to do it professionally, back in 2013. Qt is really unprofessional as a product, I remember it involved a lot of hacking and coercion of th…

Yes, that's why I said game reccomendations. I've been meaning to check out UQM for a while now.

Xonotic should run on Solaris. DarkPlaces, the engine codebase, is fairly portable last I checked.

TIS-100 runs atop Mono, but it's probably not using GPU heavily, so it'll probably run in an LX brand if you can get X up and running. As for running X11 on LX, the answer is both simple in its phrasing and hellish in its implications: X Forwarding.

I kid. Although it does seem like X forwarding is the easiest option. Luckily, you're not forwarding over the net, so you should be fine.

But yeah, it's nice to have a simple discussion about running video games in ways not intended, and what games are good, after spending a while explaining why systemd is a bad idea for the 15th time, because some people are still taken in by the sparkly unit files, and aren't paying attention to the beast lurking below the surface. (If such people are reading this thread, I'll give you a hint: Separation of concerns is a good thing, and if the process will panic the kernel if it crashes, I want it doing the job it's required to do. AND NOTHING ELSE.)

Re: Bus1: a new Linux interprocess communication proposal

#134

Post by gpderetta » Mon, Aug 22, 2016, 2:21 PM UTC

tomegun wrote: post #123

gpderetta wrote: post #121

Earlier quoted context omitted.

> o guarantee a global message order [...] > o scale with the number of CPUs available [...] It seems to me that these two goals are conflicting. If they give up the first goal then suddenly the need of a broker disappear. edit: quoting from the message linked by parent. edit2: by reading the description of the ordering guarantees, it seems that they actually only guarantee partial ordering.

One should think the goals are conflicting, but they are not. The secret is that the order is partial, as you say, but from userspace's point of view it is indistinguishable from a total order. The only messages that are not well ordered are messages that can never interact, so it is not possible to observe the lack of order from userspace. I wrote up how it works here: https://github.com/bus1/bus1/wiki/Message-order…

As long as processes communicate only via Bus1, yes, it is not possible, but there are plenty of other IPC systems on unix that can make the lack of total order manifest. Advertising it as a total order doesn't seems like a great idea.

Re: Bus1: a new Linux interprocess communication proposal

#135

Post by tomegun » Tue, Aug 23, 2016, 3:15 PM UTC

gpderetta wrote: post #134

tomegun wrote: post #123

Earlier quoted context omitted.

One should think the goals are conflicting, but they are not. The secret is that the order is partial, as you say, but from userspace's point of view it is indistinguishable from a total order. The only messages that are not well ordered are messages that can never interact, so it is not possible to observe the lack of order from userspace. I wrote up how it works here: https://github.com/bus1/bus1/wiki/Message-order…

As long as processes communicate only via Bus1, yes, it is not possible, but there are plenty of other IPC systems on unix that can make the lack of total order manifest. Advertising it as a total order doesn't seems like a great idea.

I don't see how. We should handle side-channel communication just fine. Care to give an example?

Re: Bus1: a new Linux interprocess communication proposal

#136

Post by Annatar » Wed, Aug 24, 2016, 6:50 PM UTC

chme wrote: post #24

Annatar wrote: post #16

Earlier quoted context omitted.

That's the thing about Linux: they have literally not one, but multiple armies of "programmers", and yet even after 20+ years of an absolutely furious development pace, basic things like inter-process communication still do not work desirably. Startup/shutdown? Yep, you know it already, it's still in flux (SMF in illumos has been humming along for a decade now). Filesystems? Flux. Observability? Flux. libc, what libc…

> Flux. And while all that is constantly changing, its still possible to compile very old user space software and run it in on a current kernel.

What about drivers?

On SunOS, I can install a driver built on SunOS 5.5.1 (Solaris 2.5.1) on the latest illumos or Solaris-based OS, without recompilation, thanks to the device driver interface / device driver kit ("DDI / DDK"). Solaris 2.5.1 came out in 1993; illumos came out, well, today (multiple commits every day).

Is the same possible on GNU/Linux?

Re: Bus1: a new Linux interprocess communication proposal

#137

Post by gens » Thu, Aug 25, 2016, 8:03 PM UTC

cyphar wrote: post #37

rodgerd wrote: post #4

Earlier quoted context omitted.

> what's wrong with the classical UNIX sockets Well, for starters they're a bolt-on that doesn't fit with the actual classic Unix philosophy.

You couldn't send credentials nor file descriptors to other processes without UNIX sockets. I would argue that allowing for that kind of decoupling of permissions and file access is very much in the spirit of the UNIX philosophy. Quite frankly, there are some problems you simply wouldn't be able to solve without them (in runC, the underlying runtime that Docker wraps, we use them quite extensively).

You can send fd's through UDS and they do expose a lot of info on the process on the other side.

http://www.thomasstover.com/uds.html

Re: Bus1: a new Linux interprocess communication proposal

#138

Post by gpderetta » Fri, Aug 26, 2016, 2:26 PM UTC

tomegun wrote: post #135

gpderetta wrote: post #134

Earlier quoted context omitted.

As long as processes communicate only via Bus1, yes, it is not possible, but there are plenty of other IPC systems on unix that can make the lack of total order manifest. Advertising it as a total order doesn't seems like a great idea.

I don't see how. We should handle side-channel communication just fine. Care to give an example?

proc1 sends a message to proc2 via bus1, then sends a signal to proc3 via a shared memory channel by incrementing a counter in shared memory; proc3 sees the message and signals proc4 via bus2;

There is no partial ordering between proc1->proc2 and proc3->proc4 as the memory channels are invisible to bus1, but Proc2 and proc4 can detect the total ordering violation by using another counter in shared memory.

Re: Bus1: a new Linux interprocess communication proposal

#139

Post by tomegun » Mon, Aug 29, 2016, 2:40 PM UTC

gpderetta wrote: post #138

tomegun wrote: post #135

Earlier quoted context omitted.

I don't see how. We should handle side-channel communication just fine. Care to give an example?

proc1 sends a message to proc2 via bus1, then sends a signal to proc3 via a shared memory channel by incrementing a counter in shared memory; proc3 sees the message and signals proc4 via bus2; There is no partial ordering between proc1->proc2 and proc3->proc4 as the memory channels are invisible to bus1, but Proc2 and proc4 can detect the total ordering violation by using another counter in shared memory.

Right, we only enforce the _order_ of message delivery, not the _time_ of deliver. I.e., consider the sequence of messages received on each peer, these sequences each respect a global, total order on all messages. But there are no timestamps on them, and no way to compare sequences from separate peers.