@Gordon, @Buddy,
"mountain"?? : hardly. There is no impact to existing code with this proposed change (tested). I am simply adding functionality that allows users to manually stop the thread that they started manually.? In fact I can leave the destructor of EReader the same as it was without swapping anything and just create a new function "stop()" which will allow users to disconnect cleanly if they desire to,
(Note to Gordon on your concern about the initial use of EReader during the connection, this is what the "if (m_hReadThread)" statement takes care of in the original TWS API code which is still there in my proposed change.)
Let me remind you that the current situation results in a 509 error, which is basically the API's way of saying something bad happened and I do not know what it is. Your code must be bad, which is not the case here. It is the API code that is bad. Now that we know what causes it, we can probably live with it and safely ignore it, but personally I don't like that sort of situation. If the developers intended to use this way of disconnecting the socket, then they should have properly taken care of the error message it creates. The fact that they didn't means that what they coded was unintentional and therefore is clearly a bug. A bug needs to be fixed.
However, I realise changing (adding to) the interface will make the C++ interface different than the other languages which is probably not desirable.
The only way to correct this and make the existing interface the same is to create an EMutex variable which is shared by both EReader and EClientSocket (suggest using a composition pattern here). Changes to the m_isAlive variable need to be locked by the mutex as well as inside the "while(m_isAlive)" loop. This is a larger code change and needs more care to be done right but it is not that difficult and I have implemented it successfully as well. In fact using EMutex here does not slow the loop down (checking the mutex is as simple as reading a flag) since the only time it is ever locked is when we are disconnecting which means speed is not a "critical trading" issue.
I agree it is good to have this thread capture this discussion for the record but I will definitely raise this problem to the coders as I still firmly believe this to be a bug. I do not wish to have to fix this myself every time there is a new API update.
