So, that means ns_register_proc i can call, but not ns_unregister_proc?
I have nothing against the patch if no incompabilities will be raised.
Stephen Deasey wrote:
Yes, you must still be able to register procs at runtime. (There is a
comment in urlspace.c saying you musn't call destroy at runtime...?)
I guess my real question was is this the right way to do it? I
originally thought that maybe the urlspace code should hadle all the
locking. I think the idea below is simpler and more flexible. So
here's a patch:
http://sourceforge.net/tracker/index.php?func=detail&aid=1377113&group_id=130646&atid=719009
The conn pool code is now lock free!
On 12/7/05, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
I think ns_register_proc/ns_register_filter uses Trie and canbe called
at any time, that's why it still needs locking.
Double locking should be avoided but i would keep the ability to call
ns_registerXXX procs at any time.
Stephen Deasey wrote:
Ns_ConnRunRequest in op.c does something like:
Ns_MutexLock(&ulock);
reqPtr = Ns_UrlSpecificGet(server, method, url, id);
...
Ns_MutexUnlock(&ulock);
Ns_UrlSpecificGet in urlspace.c does something like:
MkSeq(&seq, server, method, url);
Ns_MutexLock(&lock);
data = JunctionFind(&urlspace, seq, id, 0);
Ns_MutexUnlock(&lock);
i.e. there's double locking going on. The second lock, in the
urlspace code, is under contention by all callers of urlspace
(requests, url2file, etc.), and many of these are very common
operations.
Users of urlspace need to call Ns_UrlSpecificAlloc() in their
initialisation code to get a magic ID. This ID partitions the data of
each subsystem. But the ID is stored within the 'Trie' and so needs
to be protected by the global lock.
What if instead the ID was used as in Thread Local Storage? There's
an array of slots, where each slot contains a separate Trie, and the
ID is an index into this array. Because ID's are allocated at start
up and aren't destroyed there need be no locking at run time to locate
the appropriate Trie for the caller.
The urlspace locking can now be removed because the callers locking
perfectly protects the Trie from concurrent access. It would also
allow the caller to run lock-free in the case where all urlspace
entries are created at start up and only read at run time.
Does this make sense?
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
naviserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
--
Vlad Seryakov
571 262-8608 office
[EMAIL PROTECTED]
http://www.crystalballinc.com/vlad/
