Anyways, how that plays into the question of threads vs.forks is probably going to be left up to experimentation, and the quallity of the device driver code. Personally, I would fork each device off, since threads share filehandles, and other things, you may have better luck with forking and let each fork write your device status(es) to a small database( or similar file).
Additionally, you will not have to worry about 1 device malfunctioning and taking the rest down thru the thread connection, because the driver code just hangs the kernel.
Using alarm may be useful too.....but last I checked, alarm dosn't work well in threads....the parent thread intercepts all signals.....but there may be improvements in current thread code internals.
Update: I was informed by a knowledgable monk, that these are remote devices, and the device-driver hassle may not occur, since you will probably be accessing them thru the regular TCP/IP channels (internal mini-web server ,telnet, or ssh2) . But this sort of things have been asked before...and timeouts (alarms), are usually needed to make things foolproof.
In reply to Re: Testing many devices - are threads the answer?
by zentara
in thread Testing many devices - are threads the answer?
by McDarren
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |