Strange socket error

[Bob Cowdery]

Perseverance pays off in the end. Having worked out how the socket class
was supposed to work it seemed that the select call was returning when
it was not supposed to and giving a false indication in the socket set
of who spoke. When I looked at the return code of select() it was -1
(interrupted). Depending on how much of my other code was enabled the
frequency of these interruptions changed which is why I couldn't home in
on anything in particular. I don't know why the call is getting
interrupted. I don't use signals anywhere but I suspect the D library is
and possibly something to do with the receive function.

I can avoid the problem simply by sitting on the select until i get a >0
return code which means someone really did speak. I guess this does not
happen on Windows because Windows does not use signals. It's only a work
round. I would like to know why it's getting interrupted from someone
who knows the language and library implementation.

Regards
Bob

On 23/12/2010 18:28, Bob Cowdery wrote:
> Hi
> All communication is appreciated. I often find just trying to explain a
> problem can lead to fixing it. Sorry this is a bit rambling.
>
> I know D is not done yet and there will be bugs. I don't know yet if its
> me or D.
>
> The program structure is quite simple.
> 1. I have 3 pieces of C code. An interface to libusb. A library of
> signal processing functions. An embedded Mongoose HTTP server.
> 2. There is a main module which has the outer loop and it starts 4
> threads. One for the module that talks to the USB hardware. One for the
> module that talks to the signal processing library. One for the HTTP
> server and one the Web Sockets server which is also the back end of the GUI.
> 3. These threads all register their TID's with a registry module and
> then each has a receive loop. Messages are then passed between threads.
> The main threads do start some internal threads as some have more than
> one task to perform.
>
> There is no connection at all between threads except the messages that
> are passed. It is pure message passing concurrency which is one of the
> major reasons I went for D.
>
> On the web side first connection is from the browser to the HTTP server
> which simply provides the static content, html, css and js. Once the
> browser kicks itself into life it make a web socket connection to my web
> socket server and all chit chat goes on over this connection. I am
> streaming realtime graphics data to the browser and receiving data from
> it when I scroll digits, click buttons etc.
>
> The only bug that is visible in the whole app occurs in the web socket
> server as discussed. The thing I was playing with that seems to effect
> it was firstly i stopped the USB and sig processing threads from being
> created and commented out a few things so the sockets side still
> functioned. This seemed to cure the problem completly. I put back the
> sig processing thread and got the full force of the problem. In the sig
> processing thread it constructs the grapic data to send to the browser
> as series of points to plot. Even if I don't actually send the data the
> problem still occurs. However, by not constructing the last bit which is
> a Json string it reduces the problem considerably.
>
> Yes. I need to produce a smaller example that demonstrates this.
>
> Regards
> bob