Re: Why does the stack have a fixed size?
- From: Ulrich Hobelmann <u.hobelmann@xxxxxx>
- Date: Fri, 28 Oct 2005 13:53:54 +0200
Joachim Durchholz wrote:
I think the most serious problem is that OS-based schedulers introduce O(N) operations for N threads. The high-load inefficiencies are more a problem of CPU load than memory load, at least that's been my impression.
We'll see how things work out with the O(1) scheduler that was introduced in the Linux 2.6 kernels.
Yes, I'd like all thread-criticizers to retest whatever they did on a system with O(1) scheduler, to see if their criticisms still apply; my guess: no.
Posix signals are a deeply broken design anyway. Consider: you need to manipulate a global state if you want to locally catch a signal!
If you install signal-handlers, yes. But see below.
If signals are done using the processor stack, then you need a stack all right. You'd also use a stack when interfacing with external C libraries, or with the operating system.
If you use POSIX threads, there's also some system call for synchronously getting a signal value (sigwait, AFAIK, but I didn't use it yet, as I didn't do any C for a while). So you could turn off all signals and then have one thread fetch them the clean way.
Not necessarily. The only overhead is that each page is allocated separately, instead of all pages in one go.
However, if the stack is heap-based, you allocate just the same number of pages (plus probably a small O(N) overhead for memory management).
Probably you could run some static program analysis and allocate larger segments in which you fall back to stack pointer manipulation. I think that's what some of the continuations-on-stack-segments implementations do.
I think which of the two approaches is faster depends very much on specifics of OS, CPU, memory management, and GC. I'd be quite surprised if there were a clear "winner".
Well, for everything with straightforward control flow stacks are *very* fast. For extensive threading I'm not sure if something like heap-threads are better.
Does anyone have a pointer to the *implementation* of Erlang threads? I'd really like to know how they achieve process insulation, high performance, (soft?) real-time GC and all that, but can't find any information on it :(
-- The road to hell is paved with good intentions. .
- Follow-Ups:
- Re: Why does the stack have a fixed size?
- From: Joachim Durchholz
- Re: Why does the stack have a fixed size?
- References:
- Why does the stack have a fixed size?
- From: Vincenzo Ciancia
- Re: Why does the stack have a fixed size?
- From: Joachim Durchholz
- Re: Why does the stack have a fixed size?
- From: RobertSzefler
- Re: Why does the stack have a fixed size?
- From: Tony Finch
- Re: Why does the stack have a fixed size?
- From: RobertSzefler
- Re: Why does the stack have a fixed size?
- From: Florian Weimer
- Re: Why does the stack have a fixed size?
- From: RobertSzefler
- Re: Why does the stack have a fixed size?
- From: Florian Weimer
- Re: Why does the stack have a fixed size?
- From: RobertSzefler
- Re: Why does the stack have a fixed size?
- From: Joachim Durchholz
- Why does the stack have a fixed size?
- Prev by Date: Re: Why does the stack have a fixed size?
- Next by Date: Re: Why does the stack have a fixed size?
- Previous by thread: Re: Why does the stack have a fixed size?
- Next by thread: Re: Why does the stack have a fixed size?
- Index(es):
Relevant Pages
|
Loading