On 9/22/06, AgentM <agentm@themactionfaction.com> wrote:
> I would be more worried about accidental collisions between
> applications. The lock ranges will now need to be in their respective
i dont think this argument has merit because the lock is scoped to the
current database. this would only be a problem if two applications
used the same database...not likely.
the old userlocks had 48 bits of lock space and now we have 64, im not
complaining.
> application's configuration file in case of collision with another
> app once developers really start using locks for IPC. Ideally, the
> user-level lock functions would take strings instead of integers and
> hash them appropriately, no? Otherwise, someone will end up
> maintaining a registry of lock numbers in use. LISTEN doesn't use
> integers.
application can translate the locks to strings via a very simple
translation table. there is no downside to this besides a index
lookup on a small table, which is more or less what the listen/notify
does internally.
advisory locks work off of the internal lock system which is an
integer only system. the whole point is to get at these locks while
bypassing the transaction system. you are suggesting something which
does not fit into the current lock system.
merlin
