Martijn van Oosterhout wrote:
I rely on the signal handler that the JVM uses for page-faults (which a
stack overflow generally amounts to) and fpe exeptions so I know that
they will generate java exceptions in a controlled way (which I in turn
translate to elog(ERROR) on the main thread).
Well, actually, what I was thinking is if someone sends a -INT or -TERM
to the backend, which thread will catch it? You have to block it in
every thread except the one you want to catch it in if you want to
control it. This means that for any signal handler that PostgreSQL
installs, you need to intercept it with a wrapper function to make sure
it runs in the right stack.
Actually, while running backend code, you're probably fine since the
elog stuff will handle it. But if a signal is received while the JVM is
running, the signal handler will get the stack of the JVM. Now,
PostgreSQLs signal handlers tend not to do much so you may be safe.
They tend not to throws errors, but who knows...
Still, this is all solvable I think...
Yes, the signal handling in PL/Java needs a bit more work. Interrupts
doesn't work well when using PL/Java at present. This is what I plan to
do (I think this is what you mean too, right?).
Many threads are spawned by the JVM and will never enter the backend. I
can't control this and I can't add thread initialization code. Hence, I
have no way of blocking signals on a per-thread basis the normal way.
Instead, all PostgreSQL handlers that might break when called from
another thread must be replaced by a wrapper that checks the interrupted
thread. Since an arbitrary thread will receive the signal, the wrapper
must sometimes dispatch the signal to another thread. The final receiver
of the signal must be either the thread that currently executes a
backend request, or if no such thread exists, the main thread.
PL/Java will be limited to platforms that support that signals are
dispatched to specific threads. I don't consider that a limitation. I
think many JVM's have the same restriction.
Regards,
Thomas Hallgren
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
