iblck() not returning

[sbuttrick]

The 'iblck' function does not return if it tries to talk to a GPIB Gateway that is shut off.  It is causing my thread to lock up.

~~Shawn

[NI-488.2 master]

iblck does take a timeout parameter.  What value are you passing for the parameter?  What do you mean when you say your GPIB Gateway is shut off?  Are you using a GPIB-ENET/100 that is turned off?  Or do you mean that another process currently "owns" the GPIB gateway.

Craig A.
National Instruments Engineer

[sbuttrick]

By GPIB Gateway I do mean a GPIB-ENET/100.  There are some parameters being passed " iblck( gpib_gateway_id[current_gpib_gw],1,10,NULL ); "
Where can I get a description of the National Instruments functions?  I do not know what each passed parameter represents.

[ScottieB]

If you're using Windows, check the help file for function prototypes and parameter descriptions.  If you have another OS, let me know and I'll point you to the right manual, though most of the functions are the same across OS's.  For iblck:

int iblck (int ud, int v, unsigned int LockWaitTime, void * Reserved)

ud	Board unit descriptor or board index descriptor
v	Indicates whether to acquire or release the interface lock
LockWaitTime	Time period (in milliseconds) to wait for an exclusive lock before returning ELCK
Reserved	Reserved for future use; must be NULL

Seems like your command should block for 10ms and then continue.  If you're on a non-Windows OS, I may have heard of this issue.  Basically, we try to open a socket to the ethernet device and our socket request to the OS doesn't timeout for a long time (this is usually configurable in the OS itself), and this appears to be a hang.  Windows is better about failing open socket requests, if I recall correctly.

Scott B.
GPIB Software
National Instruments

Message Edited by ScottieB on 11-16-2005 10:47 AM

[sbuttrick]

I'm actually using Linux....RedHat in particular.

[Matt_S.]

Here's a good resource.

Regards,
Matt S.

[ScottieB]

Yes, this is an issue with the Linux drivers/OS.  It goes something like this:

With the Linux and Windows driver, you can do an ibfind gpib0 (assuming gpib0 is an ENET/100) with the ENET/100 turned off, and it will fail relatively quickly.  However, if you're in the middle of doing something (meaning, you already have valid sockets opened to the device) and then you shut off the GPIB-ENET/100 or it loses its network connection, the Linux OS is persistent in trying to deliver TCP packets to the device for a really long time.  Windows gives up a little sooner.  The problem is, we don't know if we are blocking for another call on the ENET/100 device (in which case we would block indefinitely, even if the call was iblck with a 10ms timout) or if the ENET/100 is completely gone.   Once the OS returns the "your socket is disconnected" error, we obviously figure it out quickly and return EDVR.  But Linux (and Unixes in general) are persistent for many many minutes so they don't give us this error for a long time.  Thus, your iblck appears to hang.

If it is a real possibility that you lose ENET connectivity in your environment, you might try to decrease the "retry time" for Linux's sockets.  This should be a configurable option somewhere, but I can't point you anywhere useful aside from Solaris's solution: the ndd command and the tcp_ip_abort_interval variable.  If that's not an option, perhaps some sort of "watchdog" thread in your application that will notice a long hang in the GPIB driver and kill it before the OS timeout.

Hope this helps.

Scott B.
GPIB Software

National Instruments