| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
| Cc: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "pgsql-hackers-win32" <pgsql-hackers-win32(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] [PATCHES] fork/exec patch |
| Date: | 2003-12-17 15:56:05 |
| Message-ID: | 28280.1071676565@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers-win32 |
"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
> The difference is that if you fire the entire signal handler on the
> different thread, which means they can execute concurrently. That won't
> happen on Unix AFAIK - the main executino is stopped, right? So the
> "main thread" could change a variable while the signal handler is still
> executing - this can never happen in Unix when the signal handler
> executes, because the main thread is stopped?
Hm, good point. There probably are some issues there for the more
complex signal handlers; they definitely assume nothing is changing
underneath them.
> An option would be to SuspendThread() on the main thread, which freezes
> it completely durnig the execution of the signal. If necessary, are we
> safe against that? (Basically, SuspendThread() will suspend a thread
> even if it's inside a kernel call.
Why would that be a problem?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2003-12-17 16:09:15 | Re: [HACKERS] [PATCHES] fork/exec patch |
| Previous Message | Magnus Hagander | 2003-12-17 15:52:51 | Re: [HACKERS] [PATCHES] fork/exec patch |