#17 Threading issue with ioport actions

[Cyrille]

This ticket is a follow-up of this thread https://groups.google.com/forum/#!topic/eibd-linknx-knxweb/h3t2l9hlBHQ

Symptoms:
With an actionlist that contains two actions of type ioport, both bound to the same ioport connection, linknx issues this error:
2013-03-11 14:02:33 [ERROR] TcpClientIOPort: Unable to connect to server for ioport pyknxcommunicator
The config is:
<actionlist>
<action data="foo" ioport="communicator" type="ioport-tx"/>
<action data="bar" ioport="communicator" type="ioport-tx"/>
</actionlist>
The ioport connection should not be permanent (permanent=false, which is the default).
The bug may appear randomly with a simpler config, though.

Causes:
It is a synchronization issue between the two action threads which share the same socket.
In the configuration described above, both actions are executed almost simultaneously, which leads to these steps:
- action 'foo' enters TcpClientIOPort::connectToServer and opens the socket
- action 'bar' enters TcpClientIOPort::connectToServer too and its thread blocks before the call to pth_connect
- action 'foo' is executed and TcpClientIOPort::disconnectFromServer closes the socket
- action 'bar' calls pth_connect and fails since socket has been closed in the previous step.

Fix:
Action threads should use their own socket to avoid threading issues. The attached patch proposes a fix for the bug by replacing connectToServer and disconnectFromServer with a RAII wrapper of the socket (the class TcpClientIOPort::Socket). TcpClientIOPort::sockfd_m is no more used in a non-permanent ioport.
I tested the fix successfully against my config. But it does not exercise the permanent ioports. I did not check whether the same buggy pattern has been duplicated to other places in the code either. Further investigation is welcome, then.