> 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.
Whoops. Guess I didn't explain how it all hung together.
The framework(apr) is to call apr_sms_thread_register()
whenever a new thread is created. The framework is also
responsible for calling apr_sms_thread_unregister whenever
a thread dies.
A simple example (using a before and after sms hierarchy).
Before:
...
| thread 1
|
sms A (count 1)
|
|
sms B (count 1)
After newly created thread:
...
| thread 1
|
sms A (count 2)
|
|
sms B (count 2)
|
|
+--- ...
| thread 2
|
sms C (count 1)
As can be read from the pseudo code in the
previous mail, A and B now perform locking and
C doesn't.
To allow an application to use an sms in another
thread it knows about, the programmer can call
apr_sms_thread_register(known_sms, os_thread_current())
to show interest manually. Ofcourse, when this
is done the programmer is also responsible for calling
apr_sms_thread_unregister().
This should only occur by exception, not by rule.
I can imagine though that there might be one
global shared memory sms (when we get around to
that) which multiple threads are to use.
Hope this clarifies things a bit more.
Sander
