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

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

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Andrew Dunstan" <andrew(at)dunslane(dot)net>,"PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>,"pgsql-hackers-win32" <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: [HACKERS] [PATCHES] fork/exec patch
Date: 2003-12-16 10:09:03
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE17156F@algol.sollentuna.se (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-hackers-win32
> Bruce Momjian wrote:
> 
> >Have you looked at the CONNX signal code on the Win32 page:
> >
> >	http://momjian.postgresql.org/main/writings/pgsql/win32.html
> >
> >It uses shared memory and events.
> >
> >  
> >
> 
> Yes, and I just did again. I guess I must be missing 
> something, though - 
> I don't see what in that code causes the signalled process to 
> call the 
> handler corresponding to the signal. Maybe I'm just a little 
> brain dead 
> today ...

Can't find that part either, but a few questions for the implementation
regardless of wether that code is around somewhere:


At what times do signals actually *need* to be delivered? And at what
points do the calling process need to be notified?

Actually interrupting a running process to execute a procedure in a
thread can be pretty darn tricky - AFAIK you have to manually switch
thread context and create an exception which you then catch, call
handler, reset and continue.

However, if it's acceptable to have delivery only when the thread is in
"alertable state" this should not be necessary. Then you can basically
take two approaches depending on when you need the response:

If you just need a response that the receiving process has queued the
thread handler, then create a separate thread that receives the signal
and queues a user APC on the main thread. This will then execute when
the thread enters alertable state.

If you need a response once it has actually run, then the main thread
needs to do signal polling now and then. This has the bad sideeffect
that the main thread will block completely until the signal is
delivered, which might be a while.

I don't know what the semantics are for kill() on unix there? And if it
is sync, does postgresql actually need that property?


Of course, I may have missed something completely as well :-)

//Magnus

Responses

pgsql-hackers by date

Next:From: Claudia D'amatoDate: 2003-12-16 10:16:38
Subject: Postgres respond after toomany times to a query view
Previous:From: Claudia D'amatoDate: 2003-12-16 09:15:18
Subject: Postgres respond after toomany times to a query view

pgsql-hackers-win32 by date

Next:From: Marek LewczukDate: 2003-12-16 10:27:40
Subject: UTF support in WIN32 native and Lower/Upper in 7.5 release
Previous:From: Dave PageDate: 2003-12-16 08:13:46
Subject: Re: Build error in src/interfaces

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