lkml.org 
[lkml]   [2003]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: So, Poll is not scalable... what to do?
Date
>Kirk Bae wrote:
>>If poll is not scalable, which method should I use when writing
>>multithreaded socket server?
>
>People who write multithreaded servers tend to use thread pools
>and never need to use poll(). (Well, ok, I've written multithreaded
>servers that used poll(), but the threads were there for disk I/O,
>not networking.)

By thread pool, do you mean, one thread per socket?, or a work-crew model
where a specified number of threads handle many sockets?


>>What is the most efficient model to use?
>>
>>Is there a "standard" model to use when writing a scalable multithreaded
>>socket serve such as "io completion ports" on windows?
>
>Depends on your definition of efficient.
>
>If by 'efficient' you mean 'runs like a bat out of hell,
>and I don't care how long it takes to write', and
>you're willing to write all the code from scratch, and
>you're handy with state machines, the right way to go is
>an edge-triggered readiness notification method (sys_epoll or kqueue,
>if available, else sigio).

My definition of "efficient" is a method that is most widely used or
accepted for writing a robust scalable server. So I guess, "'runs like a bat
out of hell, and I don't care how long it takes to write'" is close.

Would it be thread pool or epoll? Is it uncommon to mix these two?

Currently, I have a thread-1 calling poll, and dispatching its workload to
thread-2 and thread-3 in blocking sockets. I dispatch the workload to worker
threads because some of the operations take considerable time.

Is mixing threads with poll uncommon? Is this a bad design? any comments
would be appreciated.

_________________________________________________________________
Great deals on high-speed Internet access as low as $26.95.
https://broadband.msn.com (Prices may vary by service area.)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.027 / U:0.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site