On 26.10.12 21:30, Stephen Deasey wrote: > I was thinking it could work something like this: > > > - driver acquires lock, takes first conn thread off queue, releases lock > > - driver thread puts new socket in conn structure and the signals on > cond to that one thread (no locking, I don't think) > > - that conn thread wakes up, takes no locks, runs connection > > - conn thread acquires driver lock, puts conn back on front of queue, > releases lock > > > Four lock/unlock, lock/unlock sequences, two threads. you are talking here about "lock" as if we would have a single mutex. i guess, you mean connection-thread-queue-lock in the first item. What happens with the request queue (the queue of the parsed connections, realized currently via the array of connections)? Is the request queue handling missing in the paragraph above, or are you considering to get rid of it at all (which would raise further questions).
This picture is drawn from the assumption that the request queue contains one request and there is at least one connection thread waiting in the connection-thread-queue. But this is not always the case. Connection threads are not starting in 0-time; in the meanwhile many requests may be queued already. So, if a connection thread is ready to work, it should acquire a lock on the connection-thread-queue and add itself). Also, what happens if the connection thread terminates. Should it put itself in front of the connection-thread-queue as well to signal the driver to create fresh connection threads? This could address the problem we discussed recently, when the request queue is still quite full, but no new requests are coming in, but all connection threads are gone. If it adds itself as well, we could control in the driver thread and controls the liveliness of the connection threads (at least min threads running, etc.). So, i think the picture above is oversimplifying too much, but i guess the the overall message is certainly right. we can reduce the needless context switches this way. The question remains: how much is this really a problem? How much performance can be gained? Changing the notification structure (adding a connection-thread-queue and extra condition) is a relatively small change, compared to general redesign. -gustaf neumann ------------------------------------------------------------------------------ WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
