Hacker News Reader

Comment by intelVISA | Hacker News Reader

People are worried about GPT4 producing nonsense huh... articles like this prove humans still have that market on lock.

> The problem with platform threads is that they are expensive from a lot of points of view. First, they are costly to create. Whenever a platform thread is made, the OS must allocate a large amount of memory (megabytes) in the stack to store the thread context, native, and Java call stacks. This is due to the not resizable nature of the stack. Moreover, whenever the scheduler preempts a thread from execution, this enormous amount of memory must be moved around.

There are a few issues and inaccuracies in this statement.

While it is true that platform threads can be expensive in terms of resources, the claim that the OS must allocate "megabytes" of memory for the stack is an exaggeration. The actual size of the stack depends on the operating system and the specific implementation, but typical default values range from a few dozen kilobytes to a few hundred kilobytes, not megabytes.

The statement implies that the entire stack is moved around when the scheduler preempts a thread from execution. This is not accurate. When a thread is preempted, the operating system saves the context of the thread, which is a relatively small amount of data, including the values of the CPU registers and the program counter. The stack itself is not moved around during this process.

It is not correct to say that the stack is "not resizable." While the default stack size is set by the operating system, many programming languages and operating systems allow you to specify the stack size when creating a new thread. However, it is true that once a thread has been created, its stack size typically cannot be changed.

Sent from OpenAI.

> It is not correct to say that the stack is "not resizable." While the default stack size is set by the operating system, many programming languages and operating systems allow you to specify the stack size when creating a new thread. However, it is true that once a thread has been created, its stack size typically cannot be changed.

Seems like a typical confused/pendantic Stack Overflow answer. I would say that stack size is "configurable", but not "resizable", because you indeed can't change the stack size (down, at least) of an already-created OS thread.

You can create pthreads with manually allocated stack segments and resize them later.

https://www.ibm.com/docs/en/zos/2.2.0?topic=functions-pthrea...

Does that actually resize the stack in a way that the C runtime will recognize (e.g., add a guard page, making the stack size available to future calls of `pthread_getattr_get_np`)? I guess you'd only resize the stack yourself if your code was planning on somehow keeping track of the stack size, so I suppose it's not too big of a concern, but still.

The only way to resize the segment is mapping in pages at the end of the original stack, and that only works if you were careful and arranged for virtual space to be reserved and available at the end. And the only robust way to do that is to map something in. At that point might as well assign the space to the stack from the beginning. To

> The actual size of the stack depends on the operating system and the specific implementation, but typical default values range from a few dozen kilobytes to a few hundred kilobytes, not megabytes.

also lazily allocated in many implemenations

address space gets used, not memory

I would say this article is a far cry from "nonsense" - it's quite informative, even if there are a few small inaccuracies or naming issues.

There quite a few inaccuracies. The fact they are ok w/ using a naked sleep and w/o checking the interrupt flag is a flag on its own. (if you want sleep w/o exceptions use LockSupport.parkNanos not lombok)

The more glaring one is the fact that stack memory uses virtual memory space and it's not 'allocate' until used. On 64bit OS it means it's quite cheap. To me that's an unmissable, if one has spent any time doing anything with io or threads in any capacity.

There is a distinct different between parallel tasks and concurrent ones and the article seems to be confused about that part as well. (There is a reason the term is 'embarrassingly parallel' instead of 'embarrassingly concurrent')

Reply on news.ycombinator.com