On Fri, May 18, 2001 at 11:23:30AM -0700, Randall R Schulz wrote:
>Here's a snippet from the Linux section 2 manual page:
>
>...
>int select(int n, fd_set *readfds, fd_set *writefds, fd_set
>*exceptfds, struct timeval *timeout));
>...
>timeout is an upper bound on the amount of time elap
Hi,
Here's a snippet from the Linux section 2 manual page:
...
int select(int n, fd_set *readfds, fd_set *writefds, fd_set
*exceptfds, struct timeval *timeout));
...
timeout is an upper bound on the amount of time elapsed before select
returns. It may be zero, causing select to retu
On Tue, May 15, 2001 at 10:10:36AM -0400, Jason Tishler wrote:
> I just tried my Cygwin PostgreSQL 7.1.1 distribution against the latest
> Cygwin CVS and the above mentioned patch solves the postmaster shutdown
> problem. Now Cygwin PostgreSQL behaves identical to UNIX PostgreSQL
> with regard to
Corrina,
On Tue, May 15, 2001 at 11:20:54AM +0200, Corinna Vinschen wrote:
> On Fri, May 11, 2001 at 09:09:28AM +1000, Robert Collins wrote:
> > Blueskying a concept here: what about cygwin opening all sockets in
> > non-blocking mode, and if the app thinks that it is a blocking call wait
> > on
On Fri, May 11, 2001 at 09:09:28AM +1000, Robert Collins wrote:
> Blueskying a concept here: what about cygwin opening all sockets in
> non-blocking mode, and if the app thinks that it is a blocking call wait
> on the socket && on a signal event?
>
> Obviously not trivial to get working right, bu
On Mon, May 14, 2001 at 12:05:05PM +0900, Hiroshi Inoue wrote:
>Christopher Faylor wrote:
>>On Wed, May 09, 2001 at 02:26:29PM -0400, Jason Tishler wrote:
I know from inserting printfs into the backend code that the SIGTERM
signal handler function is not being called right after the stop
>
Christopher Faylor wrote:
>
> On Wed, May 09, 2001 at 02:26:29PM -0400, Jason Tishler wrote:
> >> I know from inserting printfs into the backend code that the SIGTERM
> >> signal handler function is not being called right after the stop
> >> request. Rather, it is called only after the backend ge
- Original Message -
From: "Christopher Faylor" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, May 11, 2001 4:07 AM
Subject: Re: SIGTERM does not stop backend postgres processes
immediately
>
> I'll bet the the Op
From: "Christopher Faylor" <[EMAIL PROTECTED]>
> >It is hard to see how Cygwin could emulate this in the general case if
> >closing the socket is the only way to unblock recv(win32). But what's
> >the harm in allowing signals to be handled while in recv(cygwin) even
> >if recv(win32) remains bloc
On Thu, May 10, 2001 at 03:53:40PM -0500, Fred Yankowski wrote:
>On Thu, May 10, 2001 at 02:07:21PM -0400, Christopher Faylor wrote:
>> What mechanism is this? You have already demonstrated that you can't
>> use Cygwin signals to interrupt a recv. You seem to be using circular
>> reasoning:
>
>T
On Thu, May 10, 2001 at 02:07:21PM -0400, Christopher Faylor wrote:
> What mechanism is this? You have already demonstrated that you can't
> use Cygwin signals to interrupt a recv. You seem to be using circular
> reasoning:
There are two 'recv()' APIs involved here: the Win32/winsock one, and
On Thu, May 10, 2001 at 12:36:28PM -0500, Fred Yankowski wrote:
>On Thu, May 10, 2001 at 12:31:02PM -0400, Christopher Faylor wrote:
>> Remember this?
>> >Unfortunately, blocking recv() calls are not interruptible on Windows.
>> >I'm not aware of any mechanism for allowing this.
>
>Some research l
On Thu, May 10, 2001 at 12:31:02PM -0400, Christopher Faylor wrote:
> Remember this?
> >Unfortunately, blocking recv() calls are not interruptible on Windows.
> >I'm not aware of any mechanism for allowing this.
Some research led me to believe that closesocket() could unblock a
Win32 recv() call.
On Thu, May 10, 2001 at 06:54:30PM +0200, Olivier Fambon wrote:
>Christopher Faylor wrote:
>> On Thu, May 10, 2001 at 11:26:39AM -0500, Fred Yankowski wrote:
>> >To unblock recv() on receipt of a signal -- SIGHUP in particular, for
>> >this test -- I set up a signal handler that calls close() on t
Christopher Faylor wrote:
>
> On Thu, May 10, 2001 at 11:26:39AM -0500, Fred Yankowski wrote:
> >To unblock recv() on receipt of a signal -- SIGHUP in particular, for
> >this test -- I set up a signal handler that calls close() on the
> >socket fd. It looks to me like this should call
> >fhand
To unblock recv() on receipt of a signal -- SIGHUP in particular, for
this test -- I set up a signal handler that calls close() on the
socket fd. It looks to me like this should call
fhandler_socket::close() on that fd, which then calls closesocket() on
the underlying Win32/winsock SOCKET, which
On Thu, May 10, 2001 at 11:26:39AM -0500, Fred Yankowski wrote:
>To unblock recv() on receipt of a signal -- SIGHUP in particular, for
>this test -- I set up a signal handler that calls close() on the
>socket fd. It looks to me like this should call
>fhandler_socket::close() on that fd, which the
Fred,
On Wed, May 09, 2001 at 06:08:19PM -0500, Fred Yankowski wrote:
> On Wed, May 09, 2001 at 04:48:28PM -0500, Parker, Ron wrote:
> > Under windows two things will interrupt a blocking recv() call. The first
> > is to call closesocket() from another thread.
>
> Cygwin doesn't seem to export
On Wed, May 09, 2001 at 04:48:28PM -0500, Parker, Ron wrote:
> Under windows two things will interrupt a blocking recv() call. The first
> is to call closesocket() from another thread.
Cygwin doesn't seem to export a wrapper for closesocket(). How can I
access that function? Can I call it from
> Unfortunately, blocking recv() calls are not interruptible on Windows.
> I'm not aware of any mechanism for allowing this.
Under windows two things will interrupt a blocking recv() call. The first
is to call closesocket() from another thread. The second is
WSACancelBlockingCall() which no lon
On Wed, May 09, 2001 at 02:26:29PM -0400, Jason Tishler wrote:
>> I know from inserting printfs into the backend code that the SIGTERM
>> signal handler function is not being called right after the stop
>> request. Rather, it is called only after the backend gets some data
>> over its input socke
Fred,
On Wed, May 09, 2001 at 09:40:31AM -0500, Fred Yankowski wrote:
> The problem I'm seeing, where a postgres backend process doesn't react
> immediately to SIGTERM, occurs even when there is only one such
> backend process, so this may be a different problem from the one
> described in those
I just ran 'make check' for postgres and all 76 tests passed.
The problem I'm seeing, where a postgres backend process doesn't react
immediately to SIGTERM, occurs even when there is only one such
backend process, so this may be a different problem from the one
described in those earlier threads
Fred,
On Tue, May 08, 2001 at 02:24:27PM -0500, Fred Yankowski wrote:
> This problem sounds similar to one reported in the pgsql-ports list
> earlier this year [1]. That thread concludes that it's a Cygwin
> problem, but with no solution yet. Has there been any progress since
> then?
>
> [1] h
24 matches
Mail list logo
