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

Re: Win32 signal code - first try

From: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>
To: 'Magnus Hagander ' <mha(at)sollentuna(dot)net>,'Merlin Moncure ' <merlin(dot)moncure(at)rcsonline(dot)com>
Cc: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>,'pgsql-hackers-win32 ' <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: Win32 signal code - first try
Date: 2004-01-12 22:37:31
Message-ID: A02DEC4D1073D611BAE8525405FCCE2B55F254@harris.memetrics.local (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers-win32

> > Yes, this fine for polling, but what about when the backend 
> > is *sleeping*?  As I understand the backend main processing 
> > loop, (and my understanding is far from complete...) the 
> > backend waits on 'read from socket' when it is not doing 
> > anything.  Correct me if I'm wrong, but this is not 
> > interruptible from an APC. 
> It is if you use WaitForMultipleObjectsEx(). Or if you use
> WSAEventSelect() and then WaitForSingleObjectEx() on the event (this
> emulates select() the closest)

I'd just as soon as avoid WSAEventSelect; I think that will complicate
matters quite a bit.

FWIW, in a multithreaded version of postgres I'm fooling around with, I
replaced the recv call (where backends spend most of their time waiting)
which a select(small timeout)/SleepEx(0) "busy" loop, which calls to recv
when ready. Works just fine.

Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 

pgsql-hackers-win32 by date

Next:From: Magnus HaganderDate: 2004-01-13 16:16:14
Subject: Re: Win32 signal code - first try
Previous:From: Merlin MoncureDate: 2004-01-12 17:42:43
Subject: Re: Win32 signal code - first try

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