| |||||||||||||
The ups and downs of strlcpy()The ups and downs of strlcpy()Posted Jul 28, 2012 10:41 UTC (Sat) by nix (subscriber, #2304)In reply to: The ups and downs of strlcpy() by quotemstr Parent article: The ups and downs of strlcpy()
If you find fork failing, you should either add more swap (which won't actually get used, as you note, except in the worst case) or change your program to use vfork or posix_spawn instead, both of which don't have the intrinsic commit-accounting problems of fork.Right. So I'm a mere user on a system with 250 users. fork() is failing in my Emacs so I can't start a shell (Emacs is much bigger than a shell). And your proposal for fixing this awful user interface failure is either to beg the sysadmin to add swap (I did, he said no, of course turning overcommit off was out of the question as this machine was running a database, never mind that it was a test instance that nobody was using, also it was 'like Solaris does it' and he liked Solaris) or spend time hacking at Emacs and every other program that uses fork()/exec() -- i.e. nearly everything in Unix -- so it no longer does?! This despite the fact that vfork() cannot do many of the things you do between a fork() and exec(), and posix_spawn() cannot do any of them unless the developer of posix_spawn() thought of it, hence the appallingly insane complexity of the interface? And this on a machine with almost no memory left? And this when I'm supposed to be getting something else done? Your former proposal betrays your single-user roots. Your latter proposal betrays your ignorance of what makes fork()/exec() better than the Windows model in the first place. Neither is at all times practical: the latter in particular is absolutely crackpot. Thank goodness I can turn overcommit off on my own systems.
(Log in to post comments)
The ups and downs of strlcpy() Posted Jul 28, 2012 10:43 UTC (Sat) by nix (subscriber, #2304) [Link]
The reason why my rant above sounds terribly specific is that this scenario actually happened to me. And kept happening to me, every week or so, for *years*, costing me perhaps time begging people to close other jobs down each time.
Needless to say the thought of rewriting (then X)Emacs's ferociously complex subprocess-handling infrastructure to use posix_spawn() never crossed my mind. (I tried vfork(), but that was clearly out of the question.)
The ups and downs of strlcpy() Posted Jul 31, 2012 1:30 UTC (Tue) by khc (subscriber, #45209) [Link]
nevermind that posix_spawn() uses fork/exec on linux anyway
The ups and downs of strlcpy() Posted Jul 31, 2012 23:38 UTC (Tue) by nix (subscriber, #2304) [Link]
True, so the underlying overcommit problem isn't actually fixed by it, except inasmuch as it sometimes falls back to vfork() for you. It just makes your software much much uglier, and makes it work better on major platforms such as MMU-less embedded systems, the Hurd, and Cygwin.
The ups and downs of strlcpy() Posted Aug 1, 2012 15:53 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
Emacs already uses vfork if it's available. (Read the source.) Perhaps something else was wrong with that system.
The ups and downs of strlcpy() Posted Jul 29, 2012 2:18 UTC (Sun) by foom (subscriber, #14868) [Link]
fork() is pretty evil, especially now that we have multi-threaded programs.
It would be pretty cool if you could spawn an empty process in a stopped state, and then poke at it from the parent for a bit (open up new file descriptors/etc) before causing it to exec a real subprocess.
Doing things that way would avoid all the memory accounting issues, the performance issue of copying the page table for no good reason, and the significant complication of not actually being allowed to do anything that's not async-signal-handler-safe between fork() and exec(). (And nearly nothing actually falls into that category!)
The ups and downs of strlcpy() Posted Jul 29, 2012 13:26 UTC (Sun) by nix (subscriber, #2304) [Link] It would be pretty cool if you could spawn an empty process in a stopped state, and then poke at it from the parent for a bit (open up new file descriptors/etc) before causing it to exec a real subprocess.You can do that with PTRACE_O_TRACEFORK or PTRACE_O_TRACEEXEC, but as with anything involving ptrace() there are so many tentacles that virtually any alternative is preferable.
The ups and downs of strlcpy() Posted Jul 30, 2012 1:51 UTC (Mon) by foom (subscriber, #14868) [Link]
Apparently not *any* alternative, or a new userspace API would have been merged upstream by now. :)
The ups and downs of strlcpy() Posted Jul 30, 2012 8:46 UTC (Mon) by nix (subscriber, #2304) [Link]
Yeah, true. But if ptrace() was something everyone had to use, a replacement would have been merged by now, because ptrace() is just so odious in so very many ways. (Though the improvements in recent kernels have been substantial, and in maybe as few as five to ten years I'll be able to rely on them enough to actually use them in real software, which these days means "meant to be portable between Linux distros, including the dinosaur-era RHELs too many people insist on running their bleeding-edge software on". sigh.)
The ups and downs of strlcpy() Posted Aug 1, 2012 15:50 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
> Right. So I'm a mere user on a system with 250 users
That's a rare edge case these days, like it or not. If you do regularly use such a system, it's the administrator's job to make sure system resources are adequate. The kernel is there to accurately account for system resources, not work around your sysadmin's snobbery.
> This despite the fact that vfork() cannot do many of the things you do between a fork() and exec()
Such as?
> hence the appallingly insane complexity of the interface
I don't think the interface is particularly complex. It's less complex than pthreads, certainly.
> the latter in particular is absolutely crackpot.
Do you really need to make it personal?
> Thank goodness I can turn overcommit off on my own systems
I think you mean "on".
|
|||||||||||||