Re: [HACKERS] [PATCHES] fork/exec patch - Mailing list pgsql-hackers-win32

From Magnus Hagander
Subject Re: [HACKERS] [PATCHES] fork/exec patch
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCE17157D@algol.sollentuna.se
Whole thread Raw
List 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

pgsql-hackers-win32 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] [PATCHES] fork/exec patch
Next
From: "Merlin Moncure"
Date:
Subject: Re: [HACKERS] [PATCHES] fork/exec patch