[KLUG Programming] Socket read problem

[Alan Mink]

Each thread establishes its own socket when its spawned and the threads
never terminate, unless the appl is killed or dies.

Why would it matter if there was no data to read? Wouldn't the socket read
just block until data arrived?

Thanks,
Alan
------------------------------------------------------

Adam Tauno Williams wrote:

>>I'm getting a strange error msg from the socket RECV fct, its:
>>    "Resource temporarily unavailable"
>>I have Googled this msg and the various entries imply that its an "OS" prob,
>>but there are different views as to the cause. I remove all "malloc" ops,
>>which was said to be a cause. 
>>This application runs as root and spawns a variable number of threads and
>>uses one socket per thread, in addition to a few other sockets. Sometime it
>>can run forever (a week or 2 and then I stop it) and sometime this error 
>>can occur within the 1st few seconds and then other times days later it will 
>>fail.
>>If you have any insight as to the cause (or even the source of the msg) and
>>any potential solutions, I would appreciate hearing from you.
>>    
>>
>
>1) Make really sure your threads aren't actually banging into each other
>and trying to use the same port as another thread - best to use a
>listener/dispatcher mechanism.
>
>2) Possibly your attempting to reuse a socket that is only partially
>closed from a previous connection (still in FIN WAIT).   Dead clients or
>dropped connections can leave ports out-of-service for as long as
>several minutes [ another reason to use a listener/dispatcher
>mechanism ].  What does netstat say about the status of a port when you
>see this error occur?  netstat is your friend.
>
>If the problem is caused by dead clients or dropped connections you may
>want to investigate tuning -
>net.ipv4.tcp_keepalive_intvl = 75
>net.ipv4.tcp_keepalive_probes = 9
>net.ipv4.tcp_keepalive_time = 7200
>Or if the problem is half-closed sockets you can trim the FIN wait
>parameter -
>net.ipv4.tcp_fin_timeout = 60
>
>BUT these are bandaids for an application that is not properly dealing
>with common network issues and tuning any of these values may have
>unexpected performance effects (defaults are picked for a good reason,
>often specified by RFC, adjust only with a full-on wizard level
>understanding of why).
>
>ftp://ftp.kalamazoolinux.org/pub/pdf/PerfTune2001.pdf
>
>If netstat says the socket is A-OK, are you CERTAIN there is data there
>to be read?
>
>_______________________________________________
>Programming mailing list
>Programming at kalamazoolinux.org
>http://www.kalamazoolinux.org/mailman/listinfo/programming
>
>
>
>  
>