Ok, That was what I suspected, but I was not 100% sure that it applied to
the memory allocation routines.
It has not escaped me that most things in the backend are indeed intended
for single-threading. I'm unaware of any way of coercing the Java runtime
into single threading. Instead, I took advantage of the fact that there's a
very clear border between Java and C and added a thread-fence to each an
every crossing that safely prevents other threads from entering the backend
functions. My intention is that writing functions and triggers in Java
should be far less error-prone than writing them in C. And I understand and
appreciate your concern, threading bugs are not fun to deal with.
Using a separate process is a choice I abandoned from start. I wrote a
rationale for this choice that you can find here:
http://gborg.postgresql.org/project/pljava/genpage.php?jni_rationale. I
would appreciate any comments on it very much.
Regards,
- thomas
"Tom Lane" <tgl@sss.pgh.pa.us> wrote in message
news:29909.1074267852@sss.pgh.pa.us...
> "Thomas Hallgren" <thhal@mailblocks.com> writes:
> > Is it safe to call pfree() from multiple threads?
>
> There are no multiple threads in the backend, and no provision whatever
> for thread safety. On anything, not only pfree. If your Java runtime
> cannot be coerced into a single-thread mode of operation, you would be
> well advised to keep it at arm's length in a separate process.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>
