Thread: Re: ps and psql from PostgreSQL not working with cygwin-1.1.5-2
On Tue, Oct 31, 2000 at 11:48:31AM -0500, Christopher Faylor wrote: > I can't duplicate the ps problem and I don't use psql.exe so, unless someone > can debug this, or provide more details, this will be a problem that is in > 1.1.5. Either of the two attached patches will solve the 1.1.5 psql.exe problem. I think that the first one is more correct and the second one safer (i.e., less likely to break other code). Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corporation Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com
Attachment
On Thu, Nov 02, 2000 at 12:26:34PM -0500, Jason Tishler wrote: > On Tue, Oct 31, 2000 at 11:48:31AM -0500, Christopher Faylor wrote: > > I can't duplicate the ps problem and I don't use psql.exe so, unless someone > > can debug this, or provide more details, this will be a problem that is in > > 1.1.5. > > Either of the two attached patches will solve the 1.1.5 psql.exe problem. > I think that the first one is more correct and the second one safer (i.e., > less likely to break other code). After more research, I realize that both of the above patches are wrong. Sorry for the gyrations but I went into frenzy mode due to the impending 1.1.5 release (which if I remember correctly was suppose to be yesterday)... I was also thrown off by Cygwin's strerror(EAGAIN) returning "No more processes" instead of "Resource temporarily unavailable" as on other UNIXes (at least Solaris and RedHat 6.2 Linux). Anyway, I now think that PostgreSQL's psql should be changed to deal with the possibility of errno equal to EAGAIN when connect() returns -1. See attached patch for details. Does anyone else concur? Thanks, Jason P.S. From reading the MSDN, it appears that Win32 psql should be checking for WSAEWOULDBLOCK too... -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corporation Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com
Attachment
Sorry for not letting this thread die... On Sat, Nov 04, 2000 at 01:19:50AM +0100, Corinna Vinschen wrote: > That's the problem. I thought about changing the behaviour of connect > two weeks ago. I'm not sure if it makes sense to change the error code > translation table for exactly that reason: Who knows what that would > break? Perhaps it's better to change only the connect call to return > EINPROGRESS. On the other hand Winsock seem to have interchanged the > meaning of WOULDBLOCK and INPROGRESS (by mistake?). Hmmm. Can some one very knowledgeable with socket programming (hopefully on many platforms) please help us out? Should socket clients (e.g., psql) be expected to test errno for EWOULDBLOCK (a.k.a EAGAIN) when connect() returns -1? Or, should cygwin map EWOULDBLOCK to EINPROGRESS, at least for connect()? Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corporation Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com
Jason Tishler writes: > Sorry for not letting this thread die... > > On Sat, Nov 04, 2000 at 01:19:50AM +0100, Corinna Vinschen wrote: > > That's the problem. I thought about changing the behaviour of > > connect two weeks ago. I'm not sure if it makes sense to change > > the error code translation table for exactly that reason: Who > > knows what that would break? Perhaps it's better to change only > > the connect call to return EINPROGRESS. On the other hand Winsock > > seem to have interchanged the meaning of WOULDBLOCK and > > INPROGRESS (by mistake?). Hmmm. > > Can some one very knowledgeable with socket programming (hopefully > on many platforms) please help us out? Should socket clients > (e.g., psql) be expected to test errno for EWOULDBLOCK (a.k.a > EAGAIN) when connect() returns -1? Or, should cygwin map > EWOULDBLOCK to EINPROGRESS, at least for connect()? According to POSIX, connect() should never set errno to EAGAIN or EWOULDBLOCK. (Those codes are appropriate for accept().) If the connection cannot be established immediately and O_NONBLOCK is set for the file descriptor for the socket, connect( ) shall fail and set errno to [EINPROGRESS], but the connection request shall not be aborted, and the connection shall be established asynchronously. Subsequent calls to connect( ) for the same socket, before the connection is established, shall fail and set errno to [EALREADY]. When the connection has been established asynchronously, select( ) and poll( ) shall indicate that the file descriptor for the socket is ready for writing. Upon successful completion, connect( ) shall return 0; otherwise, -1 shall be returned and errno set to indicate the error. If you want to research how sockets really behave on different platforms have a look at ACE. That is a thin wrapper that copes with the idiosyncrasies of different OSs including Win32. http://www.cs.wustl.edu/~schmidt/ACE-overview.html -- Pete Forman -./\.- Disclaimer: This post is originated Western Geophysical -./\.- by myself and does not represent pete.forman@westgeo.com -./\.- the opinion of Baker Hughes or http://www.crosswinds.net/~petef -./\.- its divisions.
On Tue, Nov 07, 2000 at 08:48:35AM +0000, Pete Forman wrote: > Jason Tishler writes: > > Sorry for not letting this thread die... I will let it die now... > > On Sat, Nov 04, 2000 at 01:19:50AM +0100, Corinna Vinschen wrote: > > > That's the problem. I thought about changing the behaviour of > > > connect two weeks ago. I'm not sure if it makes sense to change > > > the error code translation table for exactly that reason: Who > > > knows what that would break? Perhaps it's better to change only > > > the connect call to return EINPROGRESS. On the other hand Winsock > > > seem to have interchanged the meaning of WOULDBLOCK and > > > INPROGRESS (by mistake?). Hmmm. > > > > Can some one very knowledgeable with socket programming (hopefully > > on many platforms) please help us out? Should socket clients > > (e.g., psql) be expected to test errno for EWOULDBLOCK (a.k.a > > EAGAIN) when connect() returns -1? Or, should cygwin map > > EWOULDBLOCK to EINPROGRESS, at least for connect()? > > According to POSIX, connect() should never set errno to EAGAIN or > EWOULDBLOCK. (Those codes are appropriate for accept().) > > If the connection cannot be established immediately and O_NONBLOCK > is set for the file descriptor for the socket, connect( ) shall fail > and set errno to [EINPROGRESS], but the connection request shall not > be aborted, and the connection shall be established asynchronously. I'm very happy to report that Cygwin 1.1.5 has changed to implement the above. Thanks to all involved for their help. Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corporation Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com