Re: Can we simplify win32 threading code - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Can we simplify win32 threading code
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCE6C755A@algol.sollentuna.se
Whole thread Raw
In response to Can we simplify win32 threading code  ("Qingqing Zhou" <zhouqq@cs.toronto.edu>)
List 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


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Can we simplify win32 threading code
Next
From: Andrew Dunstan
Date:
Subject: Re: soundex and metaphone