Messages in this thread |  | | From | Mark Rustad <> | Subject | Re: RFC: implement daemon() in the kernel | Date | Mon, 20 Nov 2006 14:48:17 -0600 |
| |
On Nov 20, 2006, at 11:42 AM, Simon Richter wrote:
> Mark Rustad schrieb: > >> There is a better way. Simply implement fork(). It can be done >> even without an MMU. People think it is impossible, but that is >> only because they don't consider the possibility of copying memory >> back and forth on task switch. It sounds horrible, but in the vast >> majority of cases, either the parent or child either exits or does >> an exec pretty quickly, so in reality it doesn't cost much. The >> benefits are many: being able to use real shells such as bash and >> thereby being able to use real shell scripts. > > This imposes quite a significant overhead for the common case (in > which the application has specifically requested that the parent > process be terminated after the child process is fork()ed off). > Even if the cost of transferring memory contents was cheap (which > it isn't), you'd annoy the memory management subsystem unless you > did a lot of weird tricks to avoid allocating from a large block.
Yes. I did not mean to suggest that vfork() should go away or that shells that make use of it go away. It is just that making fork() work has a lot of value. vfork() would always be the optimal thing to use, but sometimes you need the power of a real fork(). Greater compatibility with normal Linux is of greater value than adding more funky special-purpose system calls.
>> You do have to look out for any applications that fork and do not >> either exit or exec, but that is so much better than having to >> modify so many things just to get them to run. > > Well, in fact just having a libc that does not define a symbol for > "fork" and then going to the places the linker mentions as having > undefined references is a pretty easy way. Mind you, in 90% of > cases you can replace them by a vfork() and be done.
Yes, but some of those 10% cases can be a real pain. Also if you are supporting users that just want some app to run, having fewer porting barriers is a real help. Often the expense of fork() is only a startup thing anyway and not a factor in the normal steady-state operation of a system.
-- Mark Rustad, MRustad@mac.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |