Hi!
I see.
I think my previous answer was a bit naiveI didn't appreciate the full scope
of the problem. Sorry for that, but you know, internet is fast, snap snap : )
Ok, for now I'm afraid I don't have any more to add. (An isolated example would
of course help greatly!)
All I can say is, in my experience, the D sockets library _does_ behave
differently on different platforms. Had a server that just died seemingly
random on osx, while working fine on Linux. Turned out to be bug in D sockets.
So there you go. (The bug is still there btw... *cough*)
Hm, also, I realize I'm not sure I quite understand the structure of your app,
and where in this structure the bug happends. Is this bug happening when your
html/5-client tries to connect to the server? Or are the threads using sockets
to communicate between eachother?
BR
/heywood
Bob Cowdery Wrote:
> Hi Heywood
>
> Thankyou for your time. Yes I agree making the call blocking does stop
> the exceptions churning. Unfortunately the application stops accepting
> data now because after the first incoming transfer from the web socket
> client it sees data on the listening socket and promptly blocks on it
> and never comes off until I make another connection. I think this is
> expected behaviour. I could spawn a thread for each connection which I
> would normally do but shouldn't need to as it's really only a few users
> and I believe that would only sidestep the real problem.
>
> There are lots of things here that don't make sense.
>
> 1. It works for Windows and it should work for Linux (and Mac) unless
> Windows is broken and Linux is behaving as it should.
> 2. I should only see data on the listen socket when I make a new
> connection. What I see is data on the listen socket when I send data on
> the connected socket and with non-blocking even when I don't make a
> connection or send any data at all.
> 2. The really confusing thing is if I stop my USB and DSP threads it
> stops behaving like this and sees data on the correct sockets. In other
> words it works as it does on Windows so I have to assume this is the
> correct behaviour.
> 3. I've played around with trying to figure out exactly what it is in
> the other threads that causes the behaviour. I got as far as finding
> that only the DSP thead is required so that rules out misbehaving USB.
> Very oddly there is a loop that is creating some Json data (not very
> efficiently) as it's doing a lot of string concatenation. If I comment
> out this loop or reduce its iterations the exception slow down to the
> point where I just get 2 and then they stop. This points to something
> horrible going on.
>
> I can only hope I've done something stupid that I just happen to be
> getting away with on Windows. If it's a bug in the compiler or libraries
> I think I'm stuffed as I wouldn't know where to start.
>
> Regards
> bob
>
> On 23/12/2010 00:20, Heywood Floyd wrote:
> > Hi Bob!
> >
> >
> > My guess: You're listener is set to be non-blocking. That means that when
> > you call listener.accept() it will return immediately with an
> > SocketAcceptException, if there's no connection. And you're basically
> > calling listener.accept() over and over again in an infinite loop.
> >
> > The following example shows it:
> >
> > import std.concurrency, std.stdio, std.conv, std.socket;
> > void main()
> > {
> > ushort port = 9999;
> > Socket listener = new TcpSocket;
> > assert(listener.isAlive);
> > listener.blocking = false;
> > listener.bind(new InternetAddress(port));
> > listener.listen(10);
> > writeln("Listening on port: ", port);
> > Socket sn;
> > while(true){
> > try
> > {
> > writeln ("Accepting");
> > sn = listener.accept();
> > writeln("Connection from ",
> > sn.remoteAddress().toString(), " established" );
> > assert(sn.isAlive);
> > assert(listener.isAlive);
> > break;
> > }
> > catch(Exception e)
> > {
> > writeln("Error accepting: ", e.toString() );
> > if(sn)
> > sn.close();
> > }
> > }
> > writeln("end");
> > }
> >
> > Running the example will print
> > Error accepting: std.socket.SocketAcceptException: Unable to accept
> > socket connection: Resource temporarily unavailable
> > for ever. (Tested on Mac.) When a user connects to 127.0.0.1:9999 (by for
> > instance opening the URL in a browser) socket.accept _does_ return a
> > connection and the program prints "end".
> >
> > I don't know why the program doesn't do this on Windows. As far as I can
> > tell the endless exceptions _is_ the correct behaviour, right?
> >
> > Anyway, if you comment out the the line
> > listener.blocking = false;
> > in 'listener.d', does it work as intended then? In the example above this
> > will cause the listener.accept()-call to actually wait until it gets a
> > connection, and thus not spew out all the exceptions.
> >
> > BR
> > /heywood
> >
> >
> >
> >
> > Bob Cowdery Wrote:
> >
> >> Hi all,
> >>
> >> This is a long shot but I'm out of ideas. I ported an app from Windows
> >> to Linux and after many issues it is working but I'm left with a strange
> >> problem. The app basically reads data streams from a USB device,
> >> processes them and outputs real-time graphical data to a browser. There
> >> is also some control input from the browser. The interface to the
> >> browser is web sockets for which I have written a D web-socket server.
> >> Depending on how much of my application I allow to run I get a stream of
> >> these errors.
> >>
> >> Error accepting: std.socket.SocketAcceptException: Unable to accept
> >> socket connection: Resource temporarily unavailable
> >> ----------------
> >> ./DcSdr() [0x80aa2ed]
> >> ./DcSdr() [0x806f52b]
> >> ./DcSdr() [0x804f752]
> >> ./DcSdr() [0x809b422]
> >> ./DcSdr() [0x80ae77e]
> >> /lib/tls/i686/cmov/libpthread.so.0(+0x596e) [0x48496e]
> >> /lib/tls/i686/cmov/libc.so.6(clone+0x5e) [0xc5fa4e]
> >>
> >> This is the web-socket accept. I seem to fall straight through the
> >> accept call even when I am not making any connection attempt. When I do
> >> connect the stream stops and I get one of these outputs each time I send
> >> data from the browser. I should not even be near the accept at that
> >> point as the connection is made.
> >>
> >> The app appears to be unaffected and works as expected. The odd think is
> >> if I shut down part of the app these errors stop. I can't tie it down to
> >> any specific thing but I suspect threading as the number of threads is
> >> reduced by stopping parts of the app. The error also seems to indicate
> >> threads are involved. I did not get this problem on Windows.
> >>
> >> Any ideas would be much appreciated.
> >>
> >> Thanks
> >> bob
>
