Hi Kevin!
I was on vacation, sorry for the delayed response.
The code you mention was experimental and I still don't have good solution
in mind.
My doubts are:
- It is not clear why TCP keep-alive mechanism didn't work
- Different OSes behave differently on the physical connection loss
- The timeout should be introduced not only for recv() but for connect()
too
- It is not clear what timeout value is good
(For example saHpiDiscover() waits until all handlers perform initial
discovery and it may take several minutes)
- If the timeout is configurable it is just another source of pain for an
HPI user.
Anton Pak
On Thu, 04 Oct 2012 17:06:40 +0400, kevin barnard <[email protected]>
wrote:
> Hi !
>
> I sent this directly to Anton, so email to the correct openhpi list
> now hopefully
>
> Some time ago on Linux I mentioned that it can take 10 minutes before
> ReadMsg() in strmsock.cpp returns when the remote hardware has been
> powered off.
>
> Just looking at the 3.2.0 stable release and I notice the changes
> related to timeout on Linux we discussed are not in there ? I guess
> it's been decided not to implement them ?
>
> i.e. the code changes in timeout.zip which introduced bool
> cStreamSock::SetBlockingMode( bool block ) and the 'Wait' test in
> ReadMsg
>
> ...
> while ( got < need ) {
> eWaitCc wcc = Wait( eWaitForRead, 3600 ); // TODO configuration?
> if ( wcc != eWaitSuccess ) {
> CRIT( "error or timeout while reading message." );
> return false;
> }
>
> Just need to check so I can add them to my code base if needed ( as
> the 10 minute timeout still seems excessive to find a remote piece of
> hardware can no longer be communicated with )
>
> regards
> kevin
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Openhpi-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
