Re: select() support / anti-load-balancing?
- From: Roland Mas <mas echo fr>
- To: orbit-list gnome org
- Subject: Re: select() support / anti-load-balancing?
- Date: 12 Feb 2001 18:12:46 +0100
Sebastian Wilhelmi (2001-02-12 15:22:44 +0100) :
> Hello Roland,
> > I'm apparently encountering some problem when several clients
> > all send requests to the same server. It seems that the first
> > client can get all the server for itself, while the other ones are
> > locked out. What would be (for me) nice was some sort of
> > round-robin on the clients, so that the server shares its
> > resources somewhat more equally.
> The server of course only has one thread of execution. So as long
> as the called method does not finish (or wait for replies for its
> own requests), no other request can be handled. That said of course
> it is possible that if there are always requests on one socket,
> other sockets won't have a chance of being heard (thats a livelock).
That's exactly what I meant, but apparently I wasn't very explicit
(and I apologize to Elliot for that).
> > So I went into the src/orb/server.c code, and it seems that the
> > server does not use select(). I feel it would help to use it, and
> > process all requests from one select() before re-select()ing.
> A select is always used, when ORBit is waiting for data.
It is true. However, the giop_check_connections() returns the
*first* connection with available data from the select(). If the
corresponding client keeps sending requests, it gets answers OK but
the other ones are locked out. (I'm not a native English speaker but
`dict livelock` tends to tell me that it's not exactly what happens.)
After having a look in the connection.c file, I still think it's
rather simple to do. I'll have to patch giop_check_connections() so
that it return a list of GIOPConnection* instead of just one. It
should then be possible to keep something like a "current" thing, and
return the next one when giop_main_next_message_2() is next called,
unless I have none left, in which case let's call
giop_check_connections() again to get a new list.
That's not very explicit, I know. I'll try to write some patch, it
should be better at communicating my meaning than I am today.
> Try ORBit-mt:
No thanks. That is not what I need. I need one thread processing
requests from several clients without locking one out. Not sure
"round-robin" is adapted either, but I need the virtual token to
Magic is one thing, and reflected-sound-of-underground-spirits is another.
-- Twoflower, in The Colour of Magic (Terry Pratchett)
] [Thread Prev