I am using the Intel tools (v1423) for prototyping a UPnP AV control point on Linux and found a small problem in the generated code. The code uses a close() of a 'dummy ' socket (called Terminate)to force the chain to leave the select() system call. This does not work as intended on Linux so the select just waits for a timeout and then continues. Though everything works, it makes the control point very irresponsive.
Apparently Linux takes the view that a file descriptor is not really closed by the close() call since the select() is still using it. It has been discussed in some Linux forums (cf. http://bugme.osdl.org/show_bug.cgi?id=1875). A small Linus quote: "That's not a bug, it's a feature. ... A threaded app that depends on some close semantics is just broken..."
Oh, well... I replaced the close() code by sending a SIGUSR1 to wake up the select (which then returns-1 with errno=EINTR), which seems to work fine.
For the rest everthing seems to work just fine under Linux, so maybe this fix can be integrated in some future release of the tools.
generated code for unblocking a chain (ILibParsers.c) not portable (Linux)
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

