Hey y'all. I got myself into what's known here in Texas as a "sitiation". That's a bad thing.
The problem is that I've inherited a rather elaborate system on Solaris 9 that makes use of three technologies
libthread.so
GPIB API ibsgnl()
GPIB-ENET/100
In English, I have a threaded application (makes use of /usr/lib/libthread.so.1) connected to a GPIB-ENET/100 box. In the application I'm calling ibsgnl() so that when an SRQ occurs on the bus, a SIGUSR1 signal should be delivered to my application. I am using version 1.4 of the GPIB-ENET/100 driver for Solaris 9.
The driver comes with a Readme file containing this statement:
1. MULTI-THREADED APPLICATION ISSUES
GPIB signal (ibsgnl) functionality does not work correctly when
linked with a thread library, for example, libthread or libpthread.
It is the act of linking that causes the problem, whether you use
any exports from the library or not. Standard signal functionality
not related to GPIB works as expected.
Well it appears that the statement is true. My application makes use of libthread. It calls ibsgnl() but it never gets the SIGUSR1.
Undaunted, I tried installing a later version of the GPIB driver (v2.4) but it didn't seem to work. Verison 2.4 appears to be for PCI cards, though the page describing the version seems to say that it works with all devices, including ENET boxes. Actually the page is a bit schizophrenic because the top part of this page
http://www.ni.com/download/ni-488.2-2.4/818/en/
says "Supported hardware" includes a whole slew of stuff including the ENET/100 hardware, but the "Description" section says that it only applies to a few GPIB cards.
I ran across this forum entry which says in "later versions" the GPIB ENET and PCI drivers can live together
however, Solaris is not mentioned there.
So my question is: is there any Solaris driver that supports GPIB-ENET/100 and overcomes the ibsgnl / libthread interference problem?