lkml.org 
[lkml]   [1999]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Kernel Threads: Dr. Russinovich's response
Date
> blocked an a select() waking up when only one is able to successfully perform
> the accept() would certainly appear to be a significant performance issue. My

Poor scaling of poll/select semantics is a well known problem. You are doing
setups for the waiting each time anyone returns. Note its possible to write
a select_begin() select_do() select_end() syscall set to keep poll like semantics
but scale more

> question is, is this a valid criticism of the kernel implementation or simply an
> out of scope criticism that is an example of poor application design? I would

Its an example of why poll has problems. Sun have been doing a lot of work
on poll/select scaling.

> Solaris. Are my expectations too high and are the criticisms brought up by Dr.
> Russ potentially going to impact me in this area?

Im not sure. I don't think his signal ones are completely right, but it
is true that for pthreads and the I/O stuff you may ultimately want a
"queue async I/O and dont make threads for it" and certainly the ability
to do CLONE_SHARE_SIGNALS for POSIX style pthreads would be good - Im sure
Ulrich would have a chunk to say on this and the Linuxthreads hackers.

My primarily contention is with the scale of problem he portrays rather than
the actual points he identifies.

He does not however seem to me to be an idiot.

Alan


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

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