On Wed, 27 Apr 2005 13:21:25 +0100 Simon Poole <[EMAIL PROTECTED]> babbled:
(B
(B> Carsten Haitzler (The Rasterman) wrote:
(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> Is there a reason why ecore_con still uses the deprecated list stuff?
(B> The ecore_list_nodes() function would be handy here. I'll port it
(B> across to the new stuff if there's no obvious impediment to doing so.
(B
(Bit hasn't been moved over. also the old stuff does work quite well and is
(Bsimple to use :)
(B
(B> What would be the preferred way to handle the fact that the new list
(B> functions don't use void* arguments? Change the type of "clients" in
(B> Ecore_Con_Server to be Ecore_List* (from Ecore_Con_Client*)? Or cast
(B> explicitly when calling the ecore_list_ functions?
(B
(Byour next mail answers that :)
(B
(B> > sooner or later clients will not be accepted anymore by the kernel
(B> > either. the question is - where do you want this control?
(B>
(B> I've looked into this. Ecore_Con is calling listen with backlog=4096.
(B> This should set the number of kernel-queued connections to 4096 unless
(B> the kernel has a lower internal limit. The Linux limit appears to 128,
(B> while "man 2 accept" says BSD's may be 5.
(B
(Byeah - i just went "all out" there :) ie "kernel - queue as much as you can -
(Bi'll get back to you asap" :)
(B
(B> Both of these limits are entirely acceptable from my applications point
(B> of view, and I will document the limitations in the code markup.
(B
(Bsounds good. :)
(B
(B> --
(B> Simon Poole
(B> www.appliancestudio.com
(B>
(B>
(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
