Re: So, Poll is not scalable... what to do?

[Mark Mielke <mark@mark.mielke.cc>]

On Thu, Nov 13, 2003 at 05:10:50PM -0600, kirk bae wrote:
> Is mixing threads with poll uncommon? Is this a bad design? any comments 
> would be appreciated.

For a portable solution involving threads, I am fond of using threads to
prioritize the scheduling. For example, a high priority thread could poll()
or select() for (the expected few) high priority events, a medium for medium,
and a low for low. Periodic events, or events that may frequently occur,
may deserve their own blocking thread.

The model probably isn't the simplest to code, though... :-)

I'm most fond of this model as the medium or lower priority threads shouldn't
wake up as often.

Another variant on this that may further reduce the overhead of poll()
is to put events that are expected to occur in the high priority
thread, and events that won't occur for some time in the low priority
thread. This variant would cause problems in the case that priority is
important, and mis-classification of an event would have an
exaggerated cost.

I suppose it really depends on the target application, as to which model
would work best...

mark

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/