4 ms·

unless a feature with the same semantics already exists in the target kernel The point is they do. For instance, Solaris has contracts (direct corollary to cgr

unless a feature with the same semantics already exists in the target kernel The point is they do. For instance, Solaris has contracts (direct corollary to cgroups, actually predating cgroups). In Solaris, orphans are adopted by the kernel and init(1M) can be restarted upon a failure condition. Some BSD flavors have procctl(2). Polling-based interfaces can work, since a port does not have to be completely equivalent in terms of benchmarking, it must conform well by a cost-benefit analysis. File system event notifications are something many platforms reliably have, so that even devices with strict power management policy can incur them (or more often than not they'll incur the cost of polling regardless). Most Unixes have converged on rfork(2)-like primitives that can customize process contexts to share reasonably well. I'm not panning systemd for anything, mind you. I'm speaking in general terms. systemd is decidedly unportable, I'm more than well aware and don't have trouble with that aspect.

JoshTriplett 11y ago
> In Solaris, orphans are adopted by the kernel and init(1M) can be restarted upon a failure condition. Some BSD flavors have procctl(2). Neither of which provides the same semantics as PR_SET_CHILD_SUBREAPER. Unless your desired target platform already has equivalent functionality, "porting" can't happen. It's easy enough to look at individual features and say "Solaris has something kinda like that" or "FreeBSD has something kinda like that". But Linux has quite a bit of functionality with no functional equivalent in other OSes. (And, conversely, some other OSes have functionality with no equivalent in Linux.) And I don't think it's unreasonable to make software that uses the full functionality of a target platform, rather than a less capable subset that can be made to work on other platforms. > Polling-based interfaces can work, since a port does not have to be completely equivalent in terms of benchmarking, Race conditions that cause you to miss events aren't OK, though. And even in terms of benchmarking, once people are done complaining about portable software, they complain that it doesn't run well on their platform. And most of the time they don't blame the platform for that.
- vezzy-fnord 11y ago
  The point was you don't need subreapers, so you'd presumably just remove the relevant code.
  - JoshTriplett 11y ago
    The kernel adopting orphaned processes doesn't make PR_SET_CHILD_SUBREAPER unnecessary. If you just wanted the processes to get reparented somewhere and reaped when they exit, you could let PID 1 do that. You also seem to have intentionally ignored the general point in favor of picking apart a specific example. The solution to all uses of non-portable interfaces isn't either "you can implement a compatibility layer using features of your target OS" or "you don't really want that code anyway, just rip it out".

JoshTriplett 11y ago

> In Solaris, orphans are adopted by the kernel and init(1M) can be restarted upon a failure condition. Some BSD flavors have procctl(2). Neither of which provides the same semantics as PR_SET_CHILD_SUBREAPER. Unless your desired target platform already has equivalent functionality, "porting" can't happen. It's easy enough to look at individual features and say "Solaris has something kinda like that" or "FreeBSD has something kinda like that". But Linux has quite a bit of functionality with no functional equivalent in other OSes. (And, conversely, some other OSes have functionality with no equivalent in Linux.) And I don't think it's unreasonable to make software that uses the full functionality of a target platform, rather than a less capable subset that can be made to work on other platforms. > Polling-based interfaces can work, since a port does not have to be completely equivalent in terms of benchmarking, Race conditions that cause you to miss events aren't OK, though. And even in terms of benchmarking, once people are done complaining about portable software, they complain that it doesn't run well on their platform. And most of the time they don't blame the platform for that.

vezzy-fnord 11y ago
The point was you don't need subreapers, so you'd presumably just remove the relevant code.
- JoshTriplett 11y ago
  The kernel adopting orphaned processes doesn't make PR_SET_CHILD_SUBREAPER unnecessary. If you just wanted the processes to get reparented somewhere and reaped when they exit, you could let PID 1 do that. You also seem to have intentionally ignored the general point in favor of picking apart a specific example. The solution to all uses of non-portable interfaces isn't either "you can implement a compatibility layer using features of your target OS" or "you don't really want that code anyway, just rip it out".