in reply to Testing many devices - are threads the answer?

The one thing I will mention, just because no one else really did, concerns the use of the term "devices". The one thing in linux (and windows) that can still lock up a machine, is a hanging device driver. Google for it.

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.


I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku
  • Comment on Re: Testing many devices - are threads the answer?