Re: select() support / anti-load-balancing?

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

Roland Mas

Magic is one thing, and reflected-sound-of-underground-spirits is another.
  -- Twoflower, in The Colour of Magic (Terry Pratchett)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]