On Fri, Mar 24, 2000 at 07:10:06PM -0500, Jim Starkey wrote:

> From: Jim Starkey <jas@...>
>
> At 05:38 PM 3/24/00 -0500, Emil Briggs wrote:
> >From: Emil Briggs <emil@...>
> >
> >
> >Thanks for the info -- not sure I understand you completely here but
> >when I make multiple connections to a Linux box running classic
> >I see one instance of the lock manager and multiple instances of
> >gds_inet_server. (One for each connection). So I am assuming that
> >each instance of gds_inet_server communicates with the lock manager
> >via Sys 5 IPC (Assumption based on the output of strace
> >on gds_lock_mgr which shows a bunch of IPC calls).
> >
>
> As it turns out, bad assumption.
>
> The Interbase generic lock manager for Unix is based on Sys-V
> shared memory (ugh) and semaphores (double ugh). However, it
> still needs to signal processes that are holding a lock blocking
> somebody in hopes they will down grade it. Unix protection
> limits to whom a process can signal. If a process finds it
> is unable to signal somebody, it asks the "gds_lock_mgr",
> running as root, to send the signal instead. A bit clunky,
> but the best that can be done on an operating system designed
> in the 1970s.

Have you tried using SIGIO instead ? Open a shared Unix socket, set it up
to send SIGIO and check the socket in the signal handler. Then pass
a message that handles the lock. In many modern Unixes you can also
check the credentials (uid,gid) of the sender of a message to a unix
socket to get some security. Otherwise just limit the processes than
can participate in the lock group by using a file system based unix
socket and appropiate access permissions on it.

Unix has come a long way since the 1970s ;)


-Andi