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 [email protected]
OP5 AB www.op5.se
Lead Developer
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]