Re: Why does the stack have a fixed size?



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.
.



Relevant Pages

  • Re: Why does the stack have a fixed size?
    ... The high-load inefficiencies are more a problem of CPU load than memory load, at least that's been my impression. ... Correct AR copying/sharing on stack is as we know very difficult, ... If signals are done using the processor stack, then you need a stack all right. ... For example copying GC can be made to allocate memory exactly as fast as stack allocation while having comparable performance upon collection. ...
    (comp.lang.functional)
  • Re: If Macs have no spyware....
    ... >had made a complete code review of its operating system and removed all ... and writing new data into those memory locations would ... >but when the data exists on the stack, it can cause very large problems. ... >location that needs to be written in place of the correct execution ...
    (comp.sys.mac.advocacy)
  • Re: If Macs have no spyware....
    ... First you yammer about being a Mac advocate, then bad mouth me for dumping XP in favor of a Mac. ... Supposedly Microsoft had made a complete code review of its operating system and removed all the buffers which could overflow. ... the fundamental problem is that the basic architecture of Windows has two fatal flaws in its memory management and while these remain in the software the ad hoc patches will never be enough to make Windows a secure operating system. ... These problems are bad enough when dealing with data in the one routine but when the data exists on the stack, it can cause very large problems. ...
    (comp.sys.mac.advocacy)
  • Re: Maybe we should stop "Paging Beth Stone" already...
    ... I'll want to work on my OS while running my OS, so the assembler that it's written with has to run under it. ... You have to swap CR3 if you want seperate memory spaces. ... The alternate stacks aren't used by the processor unless the task calls a different protection level, so they're not part of the TSS swap. ... This lets any application use up to a gigabyte of stack before Linux is forced to tell it that it's gone too far. ...
    (alt.lang.asm)
  • Re: When is "volatile" used instead of "lock" ?
    ... to get the address of a stack variable to a background thread. ... I'm suggesting that the memory model ... lock pattern works without making the instance member volatile; ... fields shared amongst more than one thread despite following the locking ...
    (microsoft.public.dotnet.languages.csharp)

Loading