dean gaudet wrote:
> suppose you're building a threaded server to scale to 20k connections,
> and you want to support fork()/exec() of CGIs dirctly (rather than
> through a separate daemon process).
>
> if you don't use close-on-exec, then after fork before exec you have
> to iterate over the 20k
On Sat, 2 Sep 2000, Alexander Viro wrote:
> On Sat, 2 Sep 2000, Jamie Lokier wrote:
>
> > dean gaudet wrote:
> > > 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
> I've heard comments from Alan, and others in the past bashing
> threads, and I can understand the "threads are for people who
> can't write state machines" comments I've heard, but what other
> ways are there of accomplishing the goals that threads solve in
> an acceptable manner that gives goo
Hi,
On Sat, Sep 02, 2000 at 09:41:03PM +0200, Ingo Molnar wrote:
>
> On Sat, 2 Sep 2000, Alexander Viro wrote:
>
> > unlink() and the last munmap()/exit() will get rid of it...
>
> yep - and this isnt possible with traditional SysV shared memory, and isnt
> possible with traditional SysV semap
Richard Gooch <[EMAIL PROTECTED]> writes:
> Ingo Molnar writes:
> > yep - and this isnt possible with traditional SysV shared memory,
> > and isnt possible with traditional SysV semaphores. (forget my
> > filesystem comment, it's a thinko.)
>
> Huh? After attaching, if you "delete" a SHMID, it w
ubject: Re: thread rant [semi-OT]
[...]
Can we do better? Yes, thanks to various programming techniques that allow
us to keep more of the system busy. The most important bottleneck is
probably the network - it makes no sense for our server to wait while a slow
client takes its time acknowledging o
ailto:[EMAIL PROTECTED]]
Sent: Saturday, September 02, 2000 1:07 AM
To: dean gaudet
Cc: Mike A. Harris; Michael Bacarella; Linux Kernel mailing list
Subject: Re: thread rant
On Sat, 2 Sep 2000, dean gaudet wrote:
> the thread bashing is mostly bashing programs which do things such as a
>
On Fri, 1 Sep 2000, Michael Bacarella wrote:
>
> Q: Why do we need threads?
> A: Because on some operating systems, task switches are expensive.
No. threads share variable and code memory, processes do not. And
sometimes it can make your life a lot easier. Even if you can use things
such as SHM
Ingo Molnar writes:
>
> On Sat, 2 Sep 2000, Alexander Viro wrote:
>
> > > what i mean is that i dont like the cleanup issues associated with SysV
> > > shared memory - eg. it can hang around even if all users have exited, so
> > > auto-cleanup of resources is not possible.
> >
> > unlink() and
On Sat, 2 Sep 2000, Alexander Viro wrote:
> > what i mean is that i dont like the cleanup issues associated with SysV
> > shared memory - eg. it can hang around even if all users have exited, so
> > auto-cleanup of resources is not possible.
>
> unlink() and the last munmap()/exit() will get ri
On Sat, 2 Sep 2000, Ingo Molnar wrote:
>
> On Sat, 2 Sep 2000, Alexander Viro wrote:
>
> > Why? I would say that bad thing about SysV shared memory is that it's
> > _not_ sufficiently filesystem-thing - a special API where 'create a
> > file on ramfs and bloody mmap() it' would be sufficient.
On Sat, 2 Sep 2000, Alexander Viro wrote:
> Why? I would say that bad thing about SysV shared memory is that it's
> _not_ sufficiently filesystem-thing - a special API where 'create a
> file on ramfs and bloody mmap() it' would be sufficient. Why bother
> with special sets of syscalls?
what i m
[EMAIL PROTECTED] (dean gaudet) wrote on 02.09.00 in
<[EMAIL PROTECTED]>:
> although you know the most amusing thing to watch a thread programmer try
> to do is to pass data bidirectionally between two sockets.
I'm tempted to say "don't do that, then". I.e., sounds like the wrong
abstraction
[EMAIL PROTECTED] (Dan Maas) wrote on 02.09.00 in
<020d01c014a9$f48d3fa0$0701a8c0@morph>:
> When people think of "multithreading," often they are just looking for a way
> to extract more concurrency from their machine. You want all these
> independent parts to be working on your task simultaneo
[EMAIL PROTECTED] (Alexander Viro) wrote on 02.09.00 in
<[EMAIL PROTECTED]>:
> *threads* *are* *hard* *to* *write* *correctly*
Not really.
The real problem is that threads - just like pointers, incidentally -
react *far* worse to getting it wrong than most abstractions do, that is,
Alexander Viro <[EMAIL PROTECTED]> writes:
> On Sat, 2 Sep 2000, Ingo Molnar wrote:
>
> > well, Linux SysV shared memory indeed has a 'software version' of
> > pagetables, this way if one process faults in a new page (because
> > all pages are unmapped originally), then the new physical page
> >
Date:Sat, 2 Sep 2000 13:08:41 +0200 (CEST)
From: Ingo Molnar <[EMAIL PROTECTED]>
i think anonymous shared memory is the way to go.
We have it now in 2.4.x, MAP_SHARED | MAP_ANONYMOUS
actually works these days. :-)
Or were you talking about creating some other kind of
"new semap
On Sat, 2 Sep 2000, Jamie Lokier wrote:
> dean gaudet wrote:
> > 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
>
On Sat, 2 Sep 2000, Ingo Molnar wrote:
> well, Linux SysV shared memory indeed has a 'software version' of
> pagetables, this way if one process faults in a new page (because all
> pages are unmapped originally), then the new physical page address can be
> discovered by all other subsequent fau
dean gaudet wrote:
> 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
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
> This is all just curiosity. I've considered trying some thread
> programming, but if it is as stupid as it sounds, I'd rather
> learn the "right" way of writing code that would ordinarily be
> done with threads, etc.. Right now, I'm using fork() all over
> the place and don't much care how muc
On Sat, 2 Sep 2000, dean gaudet wrote:
> i don't understand why another semaphore type is needed -- about the
> only semaphore missing is the pshared portion of posix. (recently i
> ported a large commercial MTA to linux and the only thing missing was
> the pthread_mutexattr_{s,g}etpshare stuff
On Sat, 2 Sep 2000, Alexander Viro wrote:
> *threads* *are* *hard* *to* *write* *correctly*
in C, yes that can be essentially true.
although you can do a webserver with no mutexes pretty easily... the first
threaded apache had exactly one mutex -- inside the memory allocator when
it had t
On Sat, 2 Sep 2000, Ingo Molnar wrote:
>
> On Fri, 1 Sep 2000, dean gaudet wrote:
>
> > yup you can do this without threads. apache-1.3+mod_ssl for example.
> >
> > but it's not fun, and it's a lot more work on the portability side.
> > inter-process shared memory and inter-process semaphor
On Sat, 2 Sep 2000, J. Dow wrote:
> Dan, another thing to consider with multithreading is that it is a way
> to avoid "convoy" effects if there is a nice priority mechanism for
> first in first out messaging. [...]
yep, this is a frequent problem at the level of the kernel. We fixed such
a (lon
On Fri, 1 Sep 2000, dean gaudet wrote:
> yup you can do this without threads. apache-1.3+mod_ssl for example.
>
> but it's not fun, and it's a lot more work on the portability side.
> inter-process shared memory and inter-process semaphores are
> notoriously different across platforms... [..
On Sat, 2 Sep 2000, dean gaudet wrote:
> the thread bashing is mostly bashing programs which do things such as a
> thread per-connection. this is the most obvious, and easy way to use
> threads, but it's not necessarily the best performance, and certainly
> doesn't scale. (on the scalability
On Fri, 1 Sep 2000, Mike A. Harris wrote:
> I've heard comments from Alan, and others in the past bashing
> threads, and I can understand the "threads are for people who
> can't write state machines" comments I've heard, but what other
> ways are there of accomplishing the goals that threads solv
> In summary, when "multithreading" floats into your mind, think
> "concurrency." Think very carefully about how you might simultaneously
> exploit all of the independent resources in your computer. Due to the long
> and complex history of OS development, a different API is usually required
> to c
> All portability issues aside, if one is writing an application in
> Linux that one would be tempted to make multithreaded for
> whatever reason, what would be the better Linux way of doing
> things?
Let's go back to basics. Look inside your computer. See what's there:
1) one (or more) CPUs
2)
(Hm, I meant for a copy of this to go to the list, too. So here it is.)
Mike Harris comments:
> > I've heard comments from Alan, and others in the past bashing
> > threads, and I can understand the "threads are for people who
> > can't write state machines" comments I've heard, but what other
> >
At 22:48 01/09/00, Michael Bacarella wrote:
>Q: Why do we need threads?
>A: Because on some operating systems, task switches are expensive.
>
>Q: So, threads are a hack to get around operating systems that suck?
>A: Basically.
urgh, i think you've missed the point.
while threads /may/ be abused
On Fri, 1 Sep 2000, Michael Bacarella wrote:
>Q: Why do we need threads?
>A: Because on some operating systems, task switches are expensive.
>
>Q: So, threads are a hack to get around operating systems that suck?
>A: Basically.
Am I understanding correctly then that using fork() is
faster/better
On Fri, 1 Sep 2000, Michael Bacarella wrote:
> Q: Why do we need threads?
> A: Because on some operating systems, task switches are expensive.
maybe this problem will help you understand threads better:
design a webserver which supports SSL session keys. consider the
performance of you
35 matches
Mail list logo
