Fork again...

[Andreas Ericsson]

Oscar Paniagua wrote:
> I think is better using threads than fork()function,

Threads are better suited for long running parts of the app. Nagios does 
threads too (as of 2.0), for sending notifications and reading the 
command-pipe f.e. Also remember that in Linux (and BSD?) fork() is 
copy-on-write, which is borderline thread-efficient if you worry about 
performance.

> Is it very difficult to change?

Not awfully, provided you can write some neat wrapper functions and use 
table indexing to register results and such. It would be a rather 
significant change though, so you will want to test it a great deal 
before submitting the patch, or Ethan will most likely reject it due to 
the possibility of bugs involved with all major changes.

> Maybe, using threads, the code is more compact and clear.
> 

Probably not. Threading generally requires more code (and more complex 
such at that). fork() also provides a small but rather significant 
safety layer. If the fork()'ed instance crashes, it doesn't necessarily 
take the master process with it as they only share the code PTE, while 
threads share all PTE's and just add a new taskstructure in kernel 
space. In essence, it means that a fork()'ed process can't fuck up the 
master's memory, while a thread can.

> Thanks a lot, I'm analysing the code before I use it,
> for this reason I made questions.
> 

I've done the same. I disagree with Ethan's coding style, but not with 
his practices in general.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl