Re: Shared memory

On Fri, Mar 24, 2006 at 11:51:30AM +0100, Thomas Hallgren wrote:
> Hi,
> I'm currently investigating the feasibility of an alternative PL/Java
> implementation that would use shared memory to communicate between a JVM
> and the backend processes. I would very much like to make use of the
> routines provided in shmem.c but I'm a bit uncertain how to add a segment
> for my own use.

I'm wondering if a better way to do it would be similar to the way X
does it. The client connects to the X server via a pipe (tcp/ip or unix
domain). This is handy because you can block on a pipe. The client then
allocates a shared memory segment and sends a message to the server,
who can then also connect to it.

The neat thing about this is that the client can put data in the shared
memory segment and send one byte through the pipe and then block on a
read. The JVM which has a thread waiting on the other end wakes up,
processes the data, puts the result back and writes a byte to the pipe
and waits. This wakes up the client who can then read the result.

No locking, no semaphores, the standard UNIX semantics on pipes and
sockets make sure everything works.

In practice you'd probably end up sending small responses exclusively
via the pipe and only use the shared memory for larger blocks of data
but that's your choice. In X this is mostly used for image data and
such.

> My questions are:
> 1. Do you see something right away that invalidates this approach?

Nothing direct, though a single segment just for finding the JVM seems
a lot. A socket approach would work better I think.

> 2. Is using the shared memory functionality that the backend provides a
> good idea (I'm thinking shmem functions, critical sections, semaphores,
> etc.). I'd rather depend on them then having conditional code for different
> operating systems.

That I don't know. However, ISTM a lock-free approach is better
wherever possible. If you can avoid the semaphores altogether...

> 3. Would it be better if the Postmaster allocated the global segment and
> started the JVM (based on some config parameter)?

I don't know about the segment but the postmaster should start. I
thought the tsearch guys had an approach using a co-process. I don't
know how they start it up but they connected via pipes.

Hope this helps,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.