[Patches] [ python-Patches-453627 ] UnixWare 7.x port for Python 2.2
noreply@sourceforge.net
noreply@sourceforge.net
Wed, 05 Sep 2001 14:40:44 -0700
Patches item #453627, was opened at 2001-08-20 22:42
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470
Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Billy G. Allie (ballie01)
Assigned to: Martin v. Löwis (loewis)
Summary: UnixWare 7.x port for Python 2.2
Initial Comment:
The attached set of patches provide work-a-rounds for
two
know UnixWare 7.x bugs and fixes other problems related
to
the UnixWare 7.x port of Python. The patch file names
and a
description of the patches are:
1. uw7_pyconfig.patch
This patch changes pyconfig.h.in to define the
following
macros when compiling on a UnixWare 7.x system:
SCO_ATAN2_BUG, SCO_ACCEPT_BUG, and
STRICT_SYSV_CURSES.
2. uw7_math.patch
This patch adds code to Modules/mathmodule.c to
work
around a bug in the SCO UnixWare atan2()
implementation.
This code is only compiled if the macro,
SCO_ATAN2_BUG,
is defined.
3. uw7_cmath.patch
This patch adds code to Modules/cmathmodule.c to
work
around a bug in the SCO UnixWare atan2()
implementation.
This code is only compiled if the macro,
SCO_ATAN2_BUG,
is defined.
4. uw7_complex.patch
This patch adds code to Objects/complexobject.c to
work
around a bug in the SCO UnixWare atan2()
implementation.
This code is only compiled if the macro,
SCO_ATAN2_BUG,
is defined.
5. uw7_socket.patch
This patch adds code to Modules/socketmodule.c to
work
around a bug in the SCO UnixWare 7.X accept()
imple-
mentation. This code is only compiled if the
macro,
SCO_ACCEPT_BUG, is defined. The patch also changed
the
code so that the accept call is restarted if it was
interrupted.
6. uw7_regrtest.patch
This patch adds a list of tests that are expected
to be
skipped for UnixWare 7.x systems.
----------------------------------------------------------------------
>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 14:40
Message:
Logged In: YES
user_id=6380
OK, so it looks like they are using signal() as a
communications mechanism.
Then I'm not sure if it's worth fixing the thread test: the
accept() call just happens to be the call that's being
interrupted by thread creation in the test, but in a real
application, *any* I/O system call can return an error with
EINTR set, and in general this will cause Python application
failures.
Maybe it's better to disable threads on UW...
----------------------------------------------------------------------
Comment By: Billy G. Allie (ballie01)
Date: 2001-09-05 14:36
Message:
Logged In: YES
user_id=8500
What I am saying that without the patch the thread test
fails because accept() returns with an error number of
EINTR. What is probably happening (guesswork here) is that
one thread started an accept() call and the main program
forked to create another process to act as a client to the
main program's server. A signal was generated during this
process that interrupted the accept() call, which returned
to the caller with errno set to EINTR.
The following text comes from fork(2) manual page:
-----------------------
Notices
Considerations for threads programming
Threads in the creating process are unaffected by these
system calls except possibly for the error indication EINTR
in the creating process.
------------------------
I forget what the exact test that failed is, but I can
replicate the failure easily enough.
----------------------------------------------------------------------
Comment By: Billy G. Allie (ballie01)
Date: 2001-09-05 14:33
Message:
Logged In: YES
user_id=8500
What I am saying that without the patch the thread test
fails because accept() returns with an error number of
EINTR. What is probably happening (guesswork here) is that
one thread started an accept() call and the main program
forked to create another process to act as a client to the
main program's server. A signal was generated during this
process that interrupted the accept() call, which returned
to the caller with errno set to EINTR.
The following text comes from fork(2) manual page:
-----------------------
Notices
Considerations for threads programming
Threads in the creating process are unaffected by these
system calls except possibly for the error indication EINTR
in the creating process.
------------------------
I forget what the exact test that failed is, but I can
replicate the failure easily enough.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 10:28
Message:
Logged In: YES
user_id=6380
Excuse me for butting in. I'm guessing that, indeed, somehow
starting threads runs a signal handler that interrupts
system calls on UW.
I would like to note that to a C programmer, it makes sense
to always retry after a SIGINT: if the signal doesn't kill
the program outright, the EINTR means that the signal
handler ran and returned, and this typically means that it
decided *not* to kill the program (the C convention is to
longjmp out). It would really be better if the system call
continued on its own accord, but for various reasons (the
"80%" argument has been mentioned) it doesn't.
But in the context of Python, a SIGINT that is intended to
"kill" (well, raise an asynchronous KeyboardInterrupt
exception) cannot use longjmp(), and our convention is that
interrupted system calls must call PyOS_InterruptOccurred()
before restarting. Unfortunately, this isn't done
consistently.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-09-05 10:04
Message:
Logged In: YES
user_id=21627
Of course: blocking calls are interupted by signals. That is
the sole purpose of SIGINT: To interrupt what the program
currently does. Python must not ignore this, but immediately
return to the caller - most likely, the user meant to
interrupt the Python program. If the application then choses
to retry on EINTR - that's a different story.
Are you saying that on UnixWare, a call to accept
immediately returns even without any signals being sent, in
the presence of threads? That sounds broken. Where is that
documented?
On the distutils patches: I'm no distutils expert, so I
don't feel qualified to review the patches (IOW, it would
take some considerable time to review them which I don't
have). Since all distutils experts have loads of patches to
review, it may take some time to find a reviewer.
----------------------------------------------------------------------
Comment By: Billy G. Allie (ballie01)
Date: 2001-09-05 08:49
Message:
Logged In: YES
user_id=8500
Any blocking I/O call is subject to being interruped by a
signal. In particular, on Unixware when running threads,
the first call to accept immediately returns because of an
interrupted call. Therefore the loop to retry the
interrupted call.
On a side note, (IMHO) the code that calls an I/O operation
that can block should check for an error code of EINTR and
retry the operation if it was interrupted instead of
returning an exception because of the interruption.
That is, of course, my own opinion.
BTW: is anyone looking at the distutils and setup.py
changes I submitted [Patch # 454041] ?
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-09-05 07:55
Message:
Logged In: YES
user_id=21627
Thanks for your patches. I've applied all of them except for
uw7_socket_2.patch. Why do you add an again loop around the
accept(2) call?
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-09-05 07:46
Message:
Logged In: YES
user_id=21627
Accepted uw7_cmath.patch, uw7_complex.patch, uw7_math.patch,
uw7_pyconfig.patch as cmathmodule.c 2.25, mathmodule.c 2.64,
complexobject.c 2.43, and pyconfig.h.in 1.6.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-09-05 07:39
Message:
Logged In: YES
user_id=21627
Accepted uw7_regrtest.patch as regrtest.py 1.46.
----------------------------------------------------------------------
Comment By: Billy G. Allie (ballie01)
Date: 2001-08-21 15:51
Message:
Logged In: YES
user_id=8500
I have uploaded an updated patch for Modules/socketmodule.py
named uw7_socket_2.patch. Please use this instead of
uw7_socket..patch. The original patch backed out 2 changes
made to socketmodule.c since I got my copy from the CVS.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453627&group_id=5470