Re: [HACKERS] [PATCHES] fork/exec patch

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 18:08:50
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE17157D@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-win32

> >>> 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?
> >>
> >> Why would that be a problem?
>
> > In a nutshell: If the main thread holds a lock on something we need
> > (such as the heap), we just shot ourselves in the foot.
>
> Hmm. Sounds like SuspendThread is not a workable option at all.

Yeah :(

Ok, moving on - would it be possible to identify a fairly limited amount
of places where we could put in a SleepEx(0) that would cause User APCs
to be called? They would then execute automatically in the context of
the correct thread.

The other way to go is to try to make the signal handlers thread safe.
Do you know offhand how much code they touch? Since they're not called
often, one could perhaps start with just wrapping all the code they
touch (and that touches the same data they do) in critical sections.
They're very lightweight and shouldn't have a noticeable performance
impact, if it's possible to identify a limited number of locations to
put it in there (as we certainly wouldn't want to bloat the code all
over the place)

//Magnus

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Merlin Moncure 2003-12-18 14:27:58 Re: [HACKERS] [PATCHES] fork/exec patch
Previous Message Tom Lane 2003-12-17 16:45:44 Re: [HACKERS] [PATCHES] fork/exec patch