my two cents about threading
Posted: Mon Nov 08, 2004 5:52 am
Just an unsolicited idea.
While nothing should preclude a plug-in from running in a thread if it wants to, it's really wasteful to force a plug-in into threading when it really doesn't need to. I know the threads in here spend almost all their time in a wait state not consuming CPU, but they do consume memory, and it adds up. If you have 50 threads sitting around in wait states, it makes it very likely for vast areas of plug-ins to get swapped out and to really page thrash when they wake up. Not to mention the thrashing that could happen when a global event they are all waiting on fires.
What if the plug-in had the option of giving a waitable object, or even multiple waitable objects to the host application? Most of the reasons a plug-in needs to thread is to wait on I/O or for timers to fire. In my instance, I had to create a thread which did nothing but wait for activity on the serial port.
When any of the waitable objects fire, the host would call a plug-in export with information needed to locate the instance, and usefully the waitable object which fired as well.
The trick is for this to be useful, the host needs to be careful about its own threads. Overlapped I/O operations live in the thread which started them, meaning the same thread needs to stick around for the operation to complete, so this would mean the plug-in callbacks would all get services from a pool of threads which don't terminate. RegisterWaitForSingleObject() actually gives a really handy way to accomplish this easily (it's >= Windows 2000, but the same thing can be done in application code with the help of QueueUserAPC () in a pool of threads doing WaitForMultipleObjects ()).
This is probably a lot of effort for a small gain, but if it isn't it would make a faster, lighter housebot server.
While nothing should preclude a plug-in from running in a thread if it wants to, it's really wasteful to force a plug-in into threading when it really doesn't need to. I know the threads in here spend almost all their time in a wait state not consuming CPU, but they do consume memory, and it adds up. If you have 50 threads sitting around in wait states, it makes it very likely for vast areas of plug-ins to get swapped out and to really page thrash when they wake up. Not to mention the thrashing that could happen when a global event they are all waiting on fires.
What if the plug-in had the option of giving a waitable object, or even multiple waitable objects to the host application? Most of the reasons a plug-in needs to thread is to wait on I/O or for timers to fire. In my instance, I had to create a thread which did nothing but wait for activity on the serial port.
When any of the waitable objects fire, the host would call a plug-in export with information needed to locate the instance, and usefully the waitable object which fired as well.
The trick is for this to be useful, the host needs to be careful about its own threads. Overlapped I/O operations live in the thread which started them, meaning the same thread needs to stick around for the operation to complete, so this would mean the plug-in callbacks would all get services from a pool of threads which don't terminate. RegisterWaitForSingleObject() actually gives a really handy way to accomplish this easily (it's >= Windows 2000, but the same thing can be done in application code with the help of QueueUserAPC () in a pool of threads doing WaitForMultipleObjects ()).
This is probably a lot of effort for a small gain, but if it isn't it would make a faster, lighter housebot server.
