Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers-win32 by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group