So in an event-driven server, how do you ...
clawrenc at xsvr1.cup.hp.com
clawrenc at xsvr1.cup.hp.com
Thu Apr 10 14:29:07 CEST 1997
In <199704071758.RAA543716 at out2.ibm.net>, on 04/07/97
at 01:39 PM, Michael Hohensee <michael at sparta.mainstream.net> said:
>It looks like you guys hate polling. (Not that I blame you, I don't
>really like it myself. :) But if you've got a system that just sits
>until the next "ripening", how do you do your IO with players? Do
>you use an endless loop to poll the connections? Or do you use the
>SIGIO signal?
Rather than re-state, from an earlier post of mine:
--<cut>--
> I am particularly interested in how your pool of threads manages socket
> connections. Are these threads dynamically created to manage connections?
> That is, do you n+1 threads managing your connections, where n is active
> connections plus one to handle connection requests on the master socket?
> Are sockets blocked or do you use some other method of activating threads?
This is really really crude, as its very long time since I looked at
this code:
One thread watches the master socket and spawns connection sockets
from there as they come in.
The child sockets then go into a pool (actually I think its a bag?)
with
a monitoring thread. Any IO to or from a socket is then assigned on
a
first available basis to a thread from a waiting pool of IO threads.
Should an IO request come in which does not have a waiting thread
ready
to execute it, a new thread is created to process the IO.
Should the number of IO threads significantly exceed the number of
open
sockets, then IO threads are killed down to a base minimum.
As such the total number of IO threads is proportional to the
current
maximum rate of IO transactions thru the system.
I could be way off here, but I think the above is fairly accurate,
well sorta, maybe.
--<cut>--
>I tried to use both. I poll for new commands from the players, and
>use the SIGIO signal to hook up a new connection. More than a
>little bit dirty. It doesn't work under BSD, then I have to poll
>for everything.
Look into the select() and poll() calls for *nix work.
--
J C Lawrence Internet: claw at null.net
(Contractor) Internet: coder at ibm.net
---------------(*) Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...
More information about the mud-dev-archive
mailing list