macOS Should I fork or thread in a server daemon?

[Cromulent]

So here is the question, should I fork or use threads in my server daemon? I'm writing a simple daemon that will listen for connection attempts and then handle them as needed. Now should I fork for every new connection or should I just create a new thread?

I am aware that forking a process requires more memory and has a slightly larger over head compared to creating a new thread but what is the accepted method for this?

 

[gnasher729]

So here is the question, should I fork or use threads in my server daemon? I'm writing a simple daemon that will listen for connection attempts and then handle them as needed. Now should I fork for every new connection or should I just create a new thread?

I am aware that forking a process requires more memory and has a slightly larger over head compared to creating a new thread but what is the accepted method for this?

Forking means a complete separate new process. So basically you have now two daemons running. Do it a few times, check Activity Monitor, and it will be filled up with this daemon.

 

[Cromulent]

Forking means a complete separate new process. So basically you have now two daemons running. Do it a few times, check Activity Monitor, and it will be filled up with this daemon.

True, but then if you run an Apache server you will see numerous instances of the http daemon. What criteria do projects such as Apache use to make the distinction between when to fork and when to thread? Do they set an arbitrary thread limit and then just fork the original to start making more threads or what?

 

[AlmostThere]

There isn't a right answer to this - Apache uses several different strategies. Google for Apache multi process module (posting from an iphone, can't copy a link ). There are several descriptions offering insight into your question and why they have the options they do.

 

[autorelease]

I'd recommend using threads to handle each request. Threads share the address space of the process, allowing multiple threads to access and modify resources and data in memory (with appropriate locking and synchronization measures, of course).

On the other hand, since child and parent processes have separate address space, you would have to use some sort of *shudder* inter-process communication to share data.

 

[Cromulent]

There isn't a right answer to this - Apache uses several different strategies. Google for Apache multi process module (posting from an iphone, can't copy a link ). There are several descriptions offering insight into your question and why they have the options they do.

Interesting thanks for that. I think I might use a method similar to this:

http://httpd.apache.org/docs/2.2/mod/worker.html

 

[Cromulent]

Hmm been playing around with this today, my first time writing a threaded application. Is there a way to dynamically create POSIX threads from within another thread?

So for instance if I have a listening thread that just listens for connections, every time it picks one up it immediately spawns another thread that then handles that client and keeps all the relevant data private from the other threads (I'm not sure on the technicalities but it seems that this a more secure approach to handling everything in one thread). Obviously from what I have read this means dynamically defining a new pthread_t variable, and then spawning a new thread using it and then merging it back when it is complete.

Has anyone got any experience with this? I'm probably missing something simple, but as I said I am pretty inexperienced with POSIX threads.

 

[pilotError]

Here's a nice little tutorial on threads

https://computing.llnl.gov/tutorials/pthreads/

I would look at Thread Pooling and worker threads.

 

[Gruffalo]

Hmm been playing around with this today, my first time writing a threaded application. Is there a way to dynamically create POSIX threads from within another thread?

So for instance if I have a listening thread that just listens for connections, every time it picks one up it immediately spawns another thread that then handles that client and keeps all the relevant data private from the other threads (I'm not sure on the technicalities but it seems that this a more secure approach to handling everything in one thread). Obviously from what I have read this means dynamically defining a new pthread_t variable, and then spawning a new thread using it and then merging it back when it is complete.

Has anyone got any experience with this? I'm probably missing something simple, but as I said I am pretty inexperienced with POSIX threads.

Well, yes, you can use pthread_create() to create a new pthread. If this is a learning excercise then you might try Butenhof's Pthreads book, it is fairly slow paced but provides pretty reasonable coverage of the subject. On the other hand, you might also do well to read something like this exposition on why you really ought to reconsider using threads at all, esp. as a self confessed novice.

Just to throw a spanner in the works, you could also consider an alternative approach. I have no idea what you are trying to achieve with your server, but you might also want to try using an approach based on select(). If you know any python at all, the asyncore module (in it's std library) is a really neat implementation. You might easily be able to prototype something without all of those nasty thread synchronization issues

 

[Cromulent]

Well, yes, you can use pthread_create() to create a new pthread. If this is a learning excercise then you might try Butenhof's Pthreads book, it is fairly slow paced but provides pretty reasonable coverage of the subject. On the other hand, you might also do well to read something like this exposition on why you really ought to reconsider using threads at all, esp. as a self confessed novice.

Just to throw a spanner in the works, you could also consider an alternative approach. I have no idea what you are trying to achieve with your server, but you might also want to try using an approach based on select(). If you know any python at all, the asyncore module (in it's std library) is a really neat implementation. You might easily be able to prototype something without all of those nasty thread synchronization issues

Thanks for the interesting post. That exposition was an interesting read but my application intentions were one of the of the few that they stated as being pretty well suited to multithreaded applications.

Python is certainly too slow and has a comparatively large overhead. I'll have a little think about the best way of going with this. I'm sure threads will cause issues but then I would have issues without any form of parallelisation anyway so at the moment it is a bit of damned if you do, damned if you don't.