Re: Can we simplify win32 threading code

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
Cc: "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Can we simplify win32 threading code
Date: 2005-05-26 14:25:23
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE6C755A@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> >>(*) the process who kill the signal:
> >> - put the signal in a *shared memory variable
> >>pg_signal_queue* and
> >>SetEvent(*shared_memory_event_variable*), then it is done;
> >>
> >>(*) the process who should receive the signal:
> >> - the main thread of this process could be awakened by the
> event from
> >>waiting status(like semop()) or
> >>CHECK_FOR_INTERRUPTS() actively; -- there is no other
> threads of this
> >>process;
> >>
> >>Any show-stop reasons of not doing this?
> >>
> >>
> >
> >Yeah, that should work. With one shared memory segment and one event
> >for each process, of course. The event can be the same one
> as is used
> >now, only it has to be named so it can be accessed externally.
>
>
> I assume that this will not break the use of pg_ctl to
> deliver pseudo-signals. That would be a show-stopper.

It shouldn't, but there is one concern: it has to be created in the
global namespace. On older windows there is no different, but on modern
windows with terminal services in it it does. It might require some
permissions hackings - I don't know what the default permissinos are on
these things. But I *think* it should work fine.

//Magnus

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2005-05-26 14:27:18 Re: soundex and metaphone
Previous Message Andrew Dunstan 2005-05-26 14:23:46 Re: Can we simplify win32 threading code