Message-ID: <4423CF32.3060406@tada.se>
Date: Fri, 24 Mar 2006 11:51:30 +0100
From: Thomas Hallgren <thomas@tada.se>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Shared memory
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

The flow I have in mind is:

Initialization:
Initialization takes place when the first PL/Java function (or validator) of the first 
session since the postmaster was started is called. The initialization process will create a 
small segment that represents the JVM. It will also start the JVM which in turn will attach 
to this segment. The JVM uses a small JNI library for this.

Session connect:
Connect takes place when the first PL/Java function (or validator) of a session is called 
(after initialization of course if its the first session).

The backend creates (or obtains, if I decide to pool them) a communication buffer of fixed 
size in shared memory. This buffer is can only be used by this backend and the JVM. The 
backend notifies the JVM of its presence using the global segment created during initialization.


My questions are:
1. Do you see something right away that invalidates this approach?
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.
3. Would it be better if the Postmaster allocated the global segment and started the JVM 
(based on some config parameter)?

All ideas and opinions are very welcome.

Kind Regards,
Thomas Hallgren