[ naviserver-Feature Requests-1377113 ] Double locking in urlspace

[SourceForge.net <no...@so...>]

Feature Requests item #1377113, was opened at 2005-12-09 06:23
Message generated for change (Settings changed) made by sdeasey
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1377113&group_id=130646

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Stephen Deasey (sdeasey)
>Assigned to: Stephen Deasey (sdeasey)
Summary: Double locking in urlspace

Initial Comment:

The code in urlspace.c has it's own private lock around
all opperations which touch the trie.  Subsystems which
call this code have their own locks with a slightly
larger scope to allow reference counting of the
urlspecific data.

Here's a longer explanation:

http://sourceforge.net/mailarchive/forum.php?thread_id=9172330&forum_id=43966



This patch moves the ID out of the trie and uses it
instead to select from one of several tries. 
Originally, there was one, global trie called urlspace.
 Now, urlspace is an array of tries, which is indexed
by ID.

All locking has been removed from the urlspace code. 
This is a potential incompatibility.

The existing core code which uses this is fine. 
Registered procedures and registered url2file procs
have their own locking. The queue.c code which assigns
requests to a particular conn pool has no locking at
all, and doesn't need it as the configuration is read
at startup and never changes.


I've changed a couple of other things.  I've removed
the ServerSpecific* procs.  It's not a very useful API
as it's just as easy to allocate server specific data
on module load and pass around a pointer in callbacks,
or failing that, uses a simple hash table.

I've also changed the output format of the
NsUrlSpecificWalk function.  It no longer returns the
virtual server name, which was redundant as you are
required to pass it to the function.  The URL and
filter are returned as two seperate elements, with the
minimal URL always being /.  A new entry is printed for
both inheriting and non inheriting data, and the data
is preceded by the work 'inherit' or 'noinherit'. 
Previously it was impossible to tell what kind of data
was registered for a URL.

This function is still a little mysterious to me.  I
wonder why you can't just build up the URL in a dstring
rather than push it all onto a stack..?




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1377113&group_id=130646