The SO_RCVTIMEO option to getsockopt/setsockopt seems to vary it's parameter format when used under Linux. With setsockopt, the parameter seems to be a struct of {long seconds, long microseconds}, as you would expect since it's modelling a C "struct timeval". However, with getsockopt, the parameter format seems to be {long seconds, long milliseconds} --- ie. it uses milliseconds rather than microseconds. The attached python script demonstrates this problem. Am I doing something crucially wrong, or is this meant to happen, or ... ? What I'm using: Python 2.2.2 (#1, Feb 24 2003, 17:36:09) [GCC 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)] on linux2
Logged In: YES user_id=33168 I just tested this on my box (Redhat 9/Linux 2.4). I get similar results with a C program as Python. (Not sure why I didn't get exactly the same results, but I'm tired.) So I'm not sure Python has a problem, since it is just exposing what is happening in C. Take a look at the C example and try it on your box. What results do you get?
Logged In: YES user_id=693152 Yes, you're right - the same thing happens with C. Here's the output from sockopt.c on my system: base (len 8) - 12, 345670 default (len 8) - 0, 0 after setsockopt (len 8) - 12, 20
Logged In: YES user_id=693152 What do we do about this? Since it does not seem to be an explciitly python problem, do we just resolve it as "Rejected" or "Wont Fix"?
Logged In: YES user_id=33168 Yes, I think this is not appropriate for Python to try to resolve. It would be very difficult to get right for all platforms. Thanks for the reminder.
