Sander Striker wrote:
Hi,
Yes, the implementation is straightforward, but not how you paint it. It is actually a lot simpler. I'll present this soon in code. [please be patient :) ]
I'll present pseudo code here to clarify what I was thinking about. I'll do the functions first and then explain how it all hangs together.
Thanks! If I understand this correctly, the only place where the thread registration logic is invoked automatically is in thread creation, right?
Coupling the registration to thread creation, rather than SMS creation, resolves some of the concerns that I listed previously. But I still have some questions about what happens during alloc/free in this model. Is your plan that the alloc/free functions should check sms->thread_count and do locking if it is greater than 1? If so, there are two problems: 1. The "sms->thread_count++" operation in the registration function is not guaranteed to be atomic. So the check of "sms->thread_count > 1" in the alloc/free functions would need to be protected by a lock. 2. There are some SMS types where no locking is needed even if the thread_count is greater than 1, for example the sms_std that just calls malloc/free.
With regard to the addition of parent_sms as an arg to apr_thread_create, am I right in assuming that NULL is valid value (meaning "don't create a stub and don't incur any locking overhead")?
--Brian
