lkml.org 
[lkml]   [2000]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: thread rant
On Sat, 2 Sep 2000, Ingo Molnar wrote:

> i dont understand why this is such an important category. If the sharing
> is very high between the threads then it makes sense to use 'shared-all
> threads'. But frequently the example given are webservers, which often do
> not have alot of cross-request shared state.

web *applications* are loaded with cross-request state. there's only so
much you can stuff in a cookie, and what application servers typically do
is stuff only a session id into the cookie and keep the rest of the
application state in memory or on disk. a good example would be a
web-based email gateway to an IMAP mail-store. (i.e. think about how to
write yahoo mail or hotmail)

web content is easy compared to web applications...

> > file descriptors -- yeesh these are hard, you want some sharing and
> > some not sharing. [...]
>
> well (in Linux) you can specify it on a per-filedescriptor level wether to
> share or not to share, and you can pass a filedescriptor to another
> process and you can establish it there. Is there any API missing in this
> area?

so even if CLONE_FILES is set i can specify i don't want files to be
shared? how does that work?

an example of brokenness in the traditional fd API is close-on-exec --
there's a race between open()/socket()/pipe() and fcntl(FD_CLOEXEC) during
which if another thread does a fork() it's possible the child will inherit
an fd it shouldn't... working around it is painful. the model which
NT/OS2 use for creating a new process scales better in the 99.99% case of
stdin/out/err -- you only specify those fds you want to keep in the new
process.

i know you've done a kick-ass job of making fd allocation not collide a
hell of a lot, but it's another synchronization that's unnecessary really.

> > other than TLB/page-table changes is there anything else i'm missing
> > which makes SMP and threading "slow"?
>
> it's not slow, it's 'slower' in the 'common memory allocation' case.

yeah malloc generally sucks because it puts synchronization in when and
the avg programmer doesn't realise it. http://www.hoard.org/ is pretty
interesting research in this area though.

-dean

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

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