It is far better to have a good library that makes things like network access and database access truly event-based (as in you don't get a "data available" event unless the data is available now). That library may use threads, but still only that library will have to be thread-aware. All the program-logic code needs not be thread aware, which means it's much simpler and less hazardous. With a good library, you never get locked.
So in the end, you're basically saying "Make the app threaded, but hide the implementation so that if you stay in a small part of the code, you won't have to deal with it". Okay. No one ever said threading had to be coded in such a way that it's out in the open with all its uglies showing. In fact, hiding implementation details behind a simple interface is one of the basics of good coding. In the end, I don't care how you organize your code... as long as it's threaded where it needs to be, I'm happy. Did I ever suggest otherwise?
Quote:
I'm saying you should have a thread only where it makes sense. I do, however think that the main logic of the program, be it a mail app or a firewall or a database should be in a single thread.
I don't think anyone was ever advocating threads for the sake of threads. If an operation is naturally serial, you shouldn't break it up. However, in the examples given (like in a mail app), there are plenty of areas where threading should be used. It looks like, in a roundabout way, we've both come to the same conclusion: Use threads.
As for single-threaded main logic in a firewall or database, though? I guess it really depends on how you plan on using it. If your database is a simple, single-user database, then fine (although, depending on how spiffy the DB's query engine is, it may use threads to speed up its search). If, however, you're talking about an enterprise-level database (i.e. hundreds or thousands of concurrent users), you don't want to attempt that with a single thread.
Comments
It is far better to have a good library that makes things like network access and database access truly event-based (as in you don't get a "data available" event unless the data is available now). That library may use threads, but still only that library will have to be thread-aware. All the program-logic code needs not be thread aware, which means it's much simpler and less hazardous. With a good library, you never get locked.
So in the end, you're basically saying "Make the app threaded, but hide the implementation so that if you stay in a small part of the code, you won't have to deal with it". Okay. No one ever said threading had to be coded in such a way that it's out in the open with all its uglies showing. In fact, hiding implementation details behind a simple interface is one of the basics of good coding. In the end, I don't care how you organize your code... as long as it's threaded where it needs to be, I'm happy. Did I ever suggest otherwise?
I'm saying you should have a thread only where it makes sense. I do, however think that the main logic of the program, be it a mail app or a firewall or a database should be in a single thread.
I don't think anyone was ever advocating threads for the sake of threads. If an operation is naturally serial, you shouldn't break it up. However, in the examples given (like in a mail app), there are plenty of areas where threading should be used. It looks like, in a roundabout way, we've both come to the same conclusion: Use threads.
As for single-threaded main logic in a firewall or database, though? I guess it really depends on how you plan on using it. If your database is a simple, single-user database, then fine (although, depending on how spiffy the DB's query engine is, it may use threads to speed up its search). If, however, you're talking about an enterprise-level database (i.e. hundreds or thousands of concurrent users), you don't want to attempt that with a single thread.