Hi, David is gone for a week, but I already wrote some stuff that might be worth reviewing/commiting.
Attached are a few patches:
sms-bugfix.patch
Fixes a bug in apr_sms_free() that snuck in.
sms-style.patch.1
More general cleanup so the code is more conformant
to the coding style guidelines as found on:
http://dev.apache.org:/styleguide.html.
sms-abort.patch.2
Adds an abort_fn member to the apr_sms_t. This
includes code calling the abort_fn, if present, on
APR_ENOMEM. The code to set the abort function is
not present yet. I added this to get sms one step
closer to apr pools.
sms-create.patch.3
Cleans up apr_sms_create() [only to be called by
memory system implementors]. It now returns a status
code which will be needed when adding lock creation
and other things that could fail in this function.
Thusfar the patches. I have been thinking about making
the code thread safe, but this will need some thought.
As someone pointed out earlier, when only one thread
is accessing the code locking is useless overhead.
Then there is the problem that apr_lock_create() takes
a pool (which we don't have).
And finally, when do we lock?
In case of the sms framework, we only need to lock when
modifying/reading the child memory system lists and the
cleanup function lists.
In case of the tracking sms we need to lock on malloc/free/
etc. I suppose this is specific to every sms and should be
implemented using a seperate lock.
Sander
sms-style.patch.1
Description: Binary data
sms-create.patch.3
Description: Binary data
sms-bugfix.patch
Description: Binary data
sms-abort.patch.2
Description: Binary data
