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.
my two cents about threading
Paul,
Thanks for sharing your thoughts. These are all good points and something that may be addressed in the future.
I've always considered the option of having threadless Devices. For Devices that don't have any other work to do except respond to Property Change events, they could simply run on notification calls from the server instead of from signaled events.
The reality is that I've never seen this as a problem yet, so I've never moved to address it. There always seems to be a bigger feature to implement vs. rework something that doesn't add a checkmark to the feature list.
Thanks for sharing your thoughts. These are all good points and something that may be addressed in the future.
I've always considered the option of having threadless Devices. For Devices that don't have any other work to do except respond to Property Change events, they could simply run on notification calls from the server instead of from signaled events.
The reality is that I've never seen this as a problem yet, so I've never moved to address it. There always seems to be a bigger feature to implement vs. rework something that doesn't add a checkmark to the feature list.
Scott