Multithreaded/Multiprocess Application

It would seem to me that inter-process sharing of data would be far more complex that inter-thread sharing of data.

If done right, there is nothing to fear from threads. Just make sure that you don't leave them in busy loops.

Regarding crashes, if a process crashes and only brings down itself, leaving the other clients untouched, then that is a big plus, on the other hand I believe in "pounding away" at the errors.

If your clients are crashing then you're not handling data correctly at some point in your code. Be it a process or a thread doesnt change the fact that to increase your code's reliability you'll have to go in and debug it.

So, in my opinion I would go with threads, they'll do what you require, and there is a lot of resources around that explain how to deal with lockouts, busy loops, etc...

Good luck! [wink]

Thanks for the input! I'll probably lean that way but I also thought I'd throw out there that a client could potentially take a lot of server time. What would the impact on that be in threads vs processes? A client could take several minutes for a single request, though that would be rare. From what I've read (since I have no experience dealing with either method) a process method is better if the client will be taking an extended period of time to complete the request.

Well, from the little that I know, and I hope I'm not wrong on this, but I think Windows prioritizes first by processes and then by threads.

This means that a process deemed of high importance will receive more processing time that another of average importance.

The same goes for threads, but threads are organized per process, therefore a medium importance thread on a low importance process will receive less processing time than a low importance thread on a high importance process.

It seems that, more than looking at processes or threads, what you need to look at is a resource manager, responsible for generating "work units" that clients can work on.

I could tell you to just spawn as many threads as there is work to be done, but thruthfully, if you're working on 10 diferent things, and you have 10 work threads, all of them reading from and writing to the drive, then they're colliding between themselfs, and competing for resources (drive time).

It's the Resource Manager's responsability to manage work in such a way that there will never be competition for a vital resource. 10 worker threads all accessing the drive at the same time will take longer than 2 worker threads in parallel, spawned 5 times, because in the first example, much time will be lost between threads waiting for the "drive resource" to be freed so they can write/read.

Hope that helped...

I'm not sure, but I *think* you could design an AbstractClient module that has all the methods a typical client would need(creation,communication...), and expose to the server that class. You then derive from AbstractClient and implement ThreadClient or ProcessClient which the server can use transparently. Then it's up to you and the needs of the application to decide whether the particular client will use a new thread or a new process.