From: Roman P. <pu...@x-...> - 2009-08-27 10:55:06
|
Hi Daniel, > > Well, it depends on the application or architecture: if > we're talking > > about io-centric worker threads (which typically reflect > the number of > > CPUs or cores), the overhead for pipes will not be large. > Have one fd > > per thread > > AFAIR the objection to such a scheme came from users like > AOLServer that have 1000s of threads, so that one extra fd > per thread would be very problematic... > absolutely true! That's why I meant "it depends on the application or architecture". My suggestions were made with my type of application in mind, and with the current solution of having one jumbo select, no benefits arise from the usage of multiple threads, so one can (basically) stick with the single-threaded version. But of course, it's still possible to attach an extension which brings in the power of multithreaded IOCP/epoll/kqueue. If Tcl (in future) wants to address performant, high-scale IO applications (like network servers), the current model has IMHO reached it's limits. It might be worth to think about a model where the user can freely decide wether or not a jumbo select is done or if a select/epoll should only take care for the thread specific fd's. BTW: are there any plans regarding IO for future releases? Have we got a roadmap? Cheers, Roman PS: thanks for the poll notifier link! |