Thorben [EMAIL PROTECTED] added the comment:
That's more like it. Now I'd like to see the same behavior on Linux...
2008/9/12 Gabriel Genellina [EMAIL PROTECTED]:
Gabriel Genellina [EMAIL PROTECTED] added the comment:
I've tested it on Windows XP. MSG_WAITALL is not supported, but I
Thorben [EMAIL PROTECTED] added the comment:
The problem exists even if the server part is replaced by a server
written in C. I only wrote up the dummy server in python to be able to
provide a testcase.
The C server works with reasonable speed when connected to a client
written in perl
Thorben [EMAIL PROTECTED] added the comment:
2008/9/11 Antoine Pitrou [EMAIL PROTECTED]:
Antoine Pitrou [EMAIL PROTECTED] added the comment:
You can use setsockopt() to set the TCP_NODELAY flag and see if that
improves things; sending thousands of 4-bytes packets isn't exactly the
expected
Thorben [EMAIL PROTECTED] added the comment:
2008/9/11 Antoine Pitrou [EMAIL PROTECTED]:
Antoine Pitrou [EMAIL PROTECTED] added the comment:
now thats interesting:
adding the line sock.setsockopt(SOL_TCP, TCP_NODELAY, 1) decreased
the delay by half. It still is extremely high but it's
Thorben Krueger [EMAIL PROTECTED] added the comment:
As promised, here is the profiler output for a Mac (thanks Stefan). The
problem does NOT occur here, which should help greatly in tracking down
the cause in the socket library. Anyone into this?
$ python runme.py
500 packets @ 2 tokens each
New submission from Thorben Krueger [EMAIL PROTECTED]:
Under Linux 2.6.24-1-amd64 as well as 2.6.26 (x86-32), Python versions
2.5.2 and 2.4.4 (on both machines), there is a huge discrepancy between
socket read latencies, depending on code context.
Some detail:
For a university project, I wrote
New submission from Thorben:
attached file makes python 2.5.1 segfault
--
components: Library (Lib)
files: curses-01.py
messages: 56348
nosy: Thorben
severity: critical
status: open
title: segfault in curses when calling redrawwin() before refresh()
type: crash
versions: Python 2.5
