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 or flat)
Thread:
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.

Cheers,
Claudio
--- 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

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-2014 The PostgreSQL Global Development Group