There are probably some differences in the socket semantics. I'd appreciate it if you could provide a patch or at least a clue!
I've not read enough Stevens to grok sockets code (yet) :-(
However, I hope that the instrumented verbose output of test_socket might give you a clue....
I've attached the diff from the version of test_socket (vs recent CVS) that I used, as well as output from test_socket on FreeBSD 4.4 and OS/2+EMX. Getting the FreeBSD issues sorted is a higher priority for me than getting OS/2+EMX working (though that would be nice too).
Please let me know if there's more testing/debugging I can do.
I've got some time for this now. Ignoring your OS/2+EMX output and focusing on the FreeBSD logs, I notice:
Testing recvfrom() in chunks over TCP. ... seg1='Michael Gilfix was he', addr='None' seg2='re ', addr='None' ERROR
Hm. This looks like recvfrom() on a TCP stream doesn't return an address; not entirely unreasonable. I wonder if self.cli_conn.getpeername() returns the expected address; can you check this? Add this after each recvfrom() call.
if addr is None: addr = self.cli_conn.getpeername()
Testing large recvfrom() over TCP. ... msg='Michael Gilfix was here ', addr='None' ERROR
Testing non-blocking accept. ... conn=<socket object, fd=8, family=2, type=1, protocol=0> addr=('127.0.0.1', 3144) FAIL
This is different. It seems that the accept() call doesn't time out. But this could be because the client thread connects too fast. Can you add a sleep (e.g. time.sleep(5)) to _testAccept() before the connect() call?
Testing non-blocking recv. ... conn=<socket object, fd=8, family=2, type=1, protocol=0> addr=('127.0.0.1', 3146) FAIL
Similar. Try putting a sleep in _testRecv() between the connect() and the send().
Let me know if you want me to provide specific patches...
--Guido van Rossum (home page: http://www.python.org/~guido/)