3 ms·
Not OP. I suppose though, that the point is that a system in which things happen serially you don't really have race conditions. Things either work, or they don
by scbrg 6y ago
Not OP. I suppose though, that the point is that a system in which things happen serially you don't really have race conditions. Things either work, or they don't. If they don't, it's because they happen in the wrong order.
One of the (very many) things that gave me and my colleagues a headache when switching to Systemd was two init scripts that could run one after the other (and the order didn't matter) but they could not run simultaneously. This had worked fine with System V style init scripts that ran serially, but started breaking in Systemd.
Of course you can now argue that this is a configuration error - however, it does not change the fact there there didn't use to be a race condition. Now there was one. One is a larger number than zero.
- hnarn 6y agoJust for the sake of discussion, if we assume any general, generic computer process that works fine serially breaks in a parallel environment, is that really a valid argument for or against parallelism? In the short term, things breaking like this are of course frustrating, but if it was my environment I’d prefer that this dependency was an explicit part of the configuration rather than something that works “by accident”, unless one prefers that initialization should never be anything but serial, but I personally at least don’t see the benefits of that outweighing what systemd offers.
- scbrg 6y ago> is that really a valid argument for or against parallelism? Not really. That wasn't the question though. The question was "were there more race condition with the parallel system than with the serial system?". The answer was undeniably, objectively yes.
- hnarn 6y agoI think the question posed is really odd, because race conditions cannot really exist as long as you only assume serial processing. I mean, the definition of a race condition means it's dependent on timing, which is an excluded risk if you're not attempting to start your services in parallel. So a better question in my opinion is: does the tradeoffs mean we should go back to serial execution? My feeling is no.
- kaba0 6y agoI mean, if they really only work when not running at the same time, they do something really really shady, so I would not really use them on production systems even in serial unless I figure out what exactly is wrong with them. It may very well be the case that they are buggy even in serial, it just not as obvious/doesn’t happen that often that way. Nonetheless, parallelism is an additional feature (in my opinion, greatly appreciated), but it can be turned off. Additional functionality is rarely bad over not having it.
- scbrg 6y ago> if they really only work when not running at the same time, they do something really really shady They configured firewall rules using iptables. I'm not sure I consider configuring firewall rules at startup using an init script "really really shady". Turns out (quite unsurprisingly) that you can't run multiple instances of the iptables command simultaneously. I don't really want to get into the whole debate about whether parallelizing startup scripts is better or not. I'm not saying it's not, but that's beside the point. The point was that parallelizing startup scripts leads to a set of problems that didn't exist before. It's annoying to see people argue that those problems don't exist. It's like arguing that the problem of flat tyres aren't more common for people driving cars than they are for people riding horses. It's utter nonsense, no matter how many other advantages cars may have.
- hnarn 6y agoWho is arguing that these problems don't exist?