Re: Embedded linux: With or without MMU

Michael Schnell wrote:
A good indication of whether or not a given Linux application will run under ucLinux is if it has a mingw windows port. Windows does not implement a "fork", ...

IMHO, "normal" applications don't spawn other independent applications. So there is no need for fork anyway.

Moreover the "standard" purpose of fork() is not to let the running application run twice, but to spawn a different executable file. And this is done with vfork() (nearly) exactly as with fork(). AFAI remember, I read, that in full Linux you can do vfork() as well (though it's not recommended) and in µCLinux you can only do vfork. It looks like in most cases the only porting effort is adding the "v" :).


There are three common uses that I can think of for (v)fork from "normal" applications. One is in forking servers, another other is for executing external subtasks, and the third is for splitting a task into parallel executed parts.

In the first case, things like webservers will often fork new processes to handle incoming connections. In this situation, it must be a real fork, since the new process keeps the same code and inherits things like file handles from the parent. This is a traditional unix server arrangement, and does not work well under ucLinux or windows ("fork" in *nix is extremely efficient using COW, but very slow if you don't have an MMU and must copy everything, or if the OS simply doesn't support the concept). Such servers need to be heavily modified to work without fork - they need to either use select() and other such asynchronous techniques, or they must use threads instead of processes. (Modern apache, for example, uses a mixture of forks and threads.)

For applications that fork off external subtasks, you normally see a fork/exec pair, often connected by a pipe to the parent. This sort of structure is normally fairly easily modified to a vfork.

For applications that use fork to parallise (is that a word?) their execution (keeping the same binary, but with different processes executing different parts of the code), it is probably better to re-write using threads. Traditionally, *nix was bad at thread handling - there was no standardisation, and it was very unclear how threads relate to processes for scheduling). Since fork was so cheap on *nix, there was no real need for threads - unlike on windows, where fork is expensive so threads were needed. But modern linux and ucLinux handle threads well, making it a good choice in many situations.

.

Relevant Pages

  • Re: Ask for help about wait() for several processes in C ,solaris
    ... >> the difference between fork and clone. ... > the usual definitions used by all modern threaded programmers. ... misused Windows processes and Windows threads. ... programmers with some experience in multiple threads and multiple ...
    (comp.programming)
  • Re: Attachments in double
    ... > I recommend using BASE64 when sending attachments to Windows. ... that has a Macintosh Resource Fork (e.g. ... You are correct that Entourage compresses twice. ...
    (microsoft.public.mac.office.entourage)
  • Re: Win32 thread vs fork
    ... fork() is a Unix word and it looks like a Perl word. ... No matter what Perl says it truly ... Funny thing in windows, ... I used to write NT 3.50/1 device drivers. ...
    (comp.lang.perl.misc)
  • Re: Parallel::ForkManager && DBI memory leak ?
    ... are you running on an MS/Windows or Unix server? ... With windows I have really bad feeling with perl. ... ...and I spend meny hours to cheat out on windoze. ... RW> is a Unix OS feature and I'm not sure that fork() is implemented ...
    (perl.dbi.users)
  • Re: Little "shadow" versions of .doc files transferred to Windows??
    ... for the file that I added from the Mac across the network by Copy and Paste. ... Disconnecting the Mac from the Windows box did not make the file go away. ... So I don't think it IS a Resource Fork. ...
    (microsoft.public.mac.office.word)