On Wed, 27 Apr 2005 16:33:49 +0100 Simon Poole <[EMAIL PROTECTED]> babbled:
(B
(B> Simon Poole wrote:
(B> > Carsten Haitzler (The Rasterman) wrote:
(B> >
(B> >>i would make 2 flags. 1. a client count limiter ( negative ==
(B> >>unlimited, 0 == too busy to accept any clients atm, 1+ == max number
(B> >>of concurrent clients.) and 2. a excess client accept policy. do they
(B> >>get instantly disconnected by ecore_con, or just ecore_con stops
(B> >>calling accept() until client count < max client count (thus allowing
(B> >>the kernel to buffer).
(B> >
(B
(Blooks fine (except for not bracketing if conditions)
(B
(Bie if (a == b && c < d) shoudl really be if ((a == b) && (c < d)) imho -
(Bbecause it makes it unambiguous as to what the coder intended. when you end up
(Bwith a big string of &&, ||'s things like a + b -c / 2 ^ g < b you start to
(Blike the extra ()'s :) anyway - other than that - looks fine :) i'll mirror the
(Bapi additions in ecore_ipc :)
(B
(B> And here's the patch that implements this behaviour. It requires my
(B> earlier patch from this thread to be applied first
(B> (ecore-0.9.9.004-ecore_con-newlists.patch). Comments please.
(B>
(B> To use, call ecore_con_server_client_limit_set(...), usually straight
(B> after ecore_con_server_add(...). All is explained in the code:
(B>
(B> /**
(B> * Sets a limit on the number of clients that can be handled concurrently
(B> * by the given server, and a policy on what to do if excess clients try to
(B> * connect.
(B> * Beware that if you set this once ecore is already running, you may
(B> * already have pending CLIENT_ADD events in your event queue. Those
(B> * clients have already connected and will not be affected by this call.
(B> * Only clients subsequently trying to connect will be affected.
(B> * @param svr The given server.
(B> * @param client_limit The maximum number of clients to handle
(B> * concurrently. -1 means unlimited (default). 0
(B> * effectively disables the server.
(B> * @param reject_excess_clients Set to 1 to automatically disconnect
(B> * excess clients as soon as they connect if you are
(B> * already handling client_limit clients. Set to 0
(B> * (default) to just hold off on the "accept()"
(B> * system call until the number of active clients
(B> * drops. This causes the kernel to queue up to 4096
(B> * connections (or your kernel's limit, whichever is
(B> * lower).
(B> * @ingroup Ecore_Con_Server_Group
(B> */
(B> void
(B> ecore_con_server_client_limit_set(Ecore_Con_Server *svr, int
(B> client_limit, char reject_excess_clients);
(B>
(B> --
(B> Simon Poole
(B> www.appliancestudio.com
(B
(B
(B--
(B------------- Codito, ergo sum - "I code, therefore I am" --------------
(BThe Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
$BMg9%B?(B [EMAIL PROTECTED]
(BTokyo, Japan ($BEl5~(B $BF|K\(B)
(B
(B
(B-------------------------------------------------------
(BSF.Net email is sponsored by: Tell us your software development plans!
(BTake this survey and enter to win a one-year sub to SourceForge.net
(BPlus IDC's 2005 look-ahead and a copy of this survey
(BClick here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
(B_______________________________________________
(Benlightenment-devel mailing list
([email protected]
(Bhttps://lists.sourceforge.net/lists/listinfo/enlightenment-devel
