Hi David, On 12/12/14 03:44, Rabbi David Botton wrote: > Sorry things have not been so exciting lately in terms of additions to Gnoga. > Core stability I think is of primary concern and if not that I am generally on > documentation. I want to be able to have a 1.0 before end of year but with out > at least a user guide I don't feel a good idea. > > So just a recap of things I see outstanding and in case someone see something > I > am missing > > 1. CPU usage > > I posted another fix that scales cpu usage better, I also know the exact issue > and have sent my current changes to Dmitry and my suggested full fix. The > issue > has to do with the way non-blocking sockets are being used. My fix splits the > working task that handles the communications in to read and write tasks, > blocks > on reads (which makes sense in any environment) and only polls the socket for > availability to send if there is data actually waiting in a queue. I am sure > he > will go with that or think of something better.
in my experience non-blocking sockets are hardly ever needed. Presumably the situation is like this: you have one task that needs to read from the socket, write to the socket, and also remove stuff to send from a queue. The problem being that if you are blocking on reading from the queue then you aren't servicing the socket, and if you are blocking on the socket then you aren't noticing items being added to the queue. One solution, which sounds like what you did, is to have one task for reading from the socket, and another for getting stuff from the queue and writing it to the socket. For the writing task, it can block on the queue, and when there is work, shove it down the socket. If there is no room in the socket then it will block, but who cares? There's no point in getting more stuff out of the queue if you can't send it due to the socket being full, you may as well block. You can always add a socket timeout, so if you block for too long you get an exception and can decide to take emergency action. A different solution is to introduce signalling sockets: as well as a socket (or sockets) for reading and writing, you have a socket in which you drop a byte to indicate that there is something in the queue. You have one task T which uses a selector to wait for activity on any of the sockets. When a task drops something off in the queue, it sends a byte down the signalling socket. When T sees from the selector that there is something in that socket, it empties it and takes the item(s) from the queue. When it sees from the selector that there is something to read from the main socket or space to write to the main socket it does that too. Ciao, Duncan. ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ Gnoga-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gnoga-list
