ae at op5.se
Thu Feb 3 21:18:11 CET 2005
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
> 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
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
More information about the Developers