delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1998/05/08/11:17:27

From: newsham AT lava DOT net (Tim Newsham)
Subject: Re: connect vs. signals
8 May 1998 11:17:27 -0700 :
Message-ID: <m0yXrHp-0011BuC.cygnus.cygwin32.developers@malasada.lava.net>
References: <199805081236 DOT IAA26510 AT kramden DOT cygnus DOT com>
Mime-Version: 1.0
To: cgf AT cygnus DOT com (Christopher Faylor)
Cc: cygwin32-developers AT cygnus DOT com, newsham AT lava DOT net

> If I remember correctly, it wasn't a race condition, was it?  I thought

Let me clarify.  The race condition I mention is when a signal
comes in at the right time (which is, when the connect winsock call
is active). 

> things just behaved badly in a user supplied signal handler routine
> if connect was interrupted.  Putting these around the i_connect call
> makes the connect uninterruptable.  Is that correct?

The race condition only manifests itself when things are done
before the connect code continues.  If the signal is not handled
or if the signal handler does not perform certain actions and
lets the connect code continue, then the problem does not manifest
itself.  But it is perfectly legal to jump out of a signal handler
never to return, or to use sockets while in a signal handler.

> cgf

                                         Tim N.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019