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.

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.

Logged In: YES 
user_id=21627

Accepted uw7_regrtest.patch  as regrtest.py 1.46.

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.

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?

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] ?

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.

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.

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.

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.

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...

Logged In: YES 
user_id=8500

I have uploaded a new patch, uw7_atan2fix.patch, that
changes the sco_atan2() routine so that negitive zero as the
first argument is handled correctly.  The previous version
did not handle -0 correctly (as pointed out by Tim Peters). 
This patch assumes that the previous patches have been
applied.

Logged In: YES 
user_id=31435

I suggest instead reverting all changes to atan2 and simply 
documenting that this platform has some libm bugs.  
Detailed review of math patches takes intense effort and I 
don't have time for that; and that's bad, because you're 
unlikely to get this right unless you're a libm expert (for 
example, atan2() applied to two minus zeroes should return 
minus pi, not a minus 0 as in the new patch -- if writing 
correct libm functions were easy, UnixWare wouldn't have 
screwed it up to begin with <wink>).

Logged In: YES 
user_id=21627

I have reverted the atan2 changes, and added a note to
README explaining the problem. Since both parts of the
socket patch have been questioned, I reject it also. If you
think anything needs to be done here, please submit a new
patch.

Closing this patch, as
partially-accepted-partially-rejected.