guys...
I wrote the plugin/player.
The issue literally is, that the code flow goes like this:
* Start DCE device
* Get DCE stuff set up
* Start LIRCD Thread
Once the LIRCD thread starts, then...
* Open fake LIRCD server socket
* wait for connections.
^^ -- Right there, it blocks.
What this means is, the execution of this thread _STOPS_ until a connection is made.
For those of you who haven't done any threaded programming, A thread is a lightweight process started within another program, it runs autonomously. Typically, stuff like this runs in a loop, where it will simply ask if a connection is pending, if so, then it will continue with the next set of stuff to do, otherwise, it will simply loop away and ask again after waiting a few microseconds. Typically, if the main thread needs to quit, it will set a method variable that's used as a flag, that the other threads can point back to and look at, a quit flag. If this is set, then the thread can take steps to break out of its loops, and close itself out. When the main device's thread recieves a quit, I subclass its quit method, so that it can join the LIRCd thread, and wait for it to stop. It joins the LIRCd thread, but since it is still waiting for the accept, it never stops. So it just sits there, even after the parent DCE thread has completely quit and is waiting on my little joined thread to stop.
Non-blocking socket code is more difficult to write, because either you have to constantly poll your connections in your main loop, or you have to create more complex methods of threading and polling with callbacks to respond to changes in the connection state, so when I was writing this code, I opted to write code as simple as possible.
So what's happening, is the code in that thread is stopping at the accept() call, and not executing anything else. So even though m_bQuit gets set, it doesn't matter, because the other thread is still sitting there, waiting for a connection.
The code needs to be rewritten to properly non-block. This means using select() to check the status of the LIRCd socket when waiting for a connection, and when dealing with the connection.
The server code is vastly simplified BECAUSE we only have to deal with one client at a time, there aren't multiple connections, so it's basically just two loops sitting next to each other, and no multiplexing is done...
If lircd were TCP socket based, I suspect I could just use the Pluto plain client socket stuff...but it's not.. it's a UNIX socket.. although, would be nice for someone to look into it, before I come back to it...
anyway... I hope this explanation clears up the percieved behaviour and what is actually happening.
-Thom
