Stop being cringe and adopt the same stack size as everyone else. Oh my god. What on earth are you saving?
IMO: it's nice to have weird platforms. I've caught lurking UDB and memory corruption in my programs by trying to run them on weird OSes.
Understanding thread stack sizes and how Alpine is different
31–40 of 81 posts
Re: Understanding thread stack sizes and how Alpine is different
#32Why would you overcomplicate your life and use something like the autofree example, that is not even portable, if you can use the heap which is simple to understand and do? I understand that if it is a hot function you may run into memory fragmentation/performance issues, but there are some many ways to deal with that with custom allocators if it truly is a problem. This is one of those perfect examples where simple is better IMHO
Re: Understanding thread stack sizes and how Alpine is different
#33I remember reading about arguments over whether Algol should permit recursive procedures, where one side of the argument was apparently claiming that they wouldn't be possible to implement. That seems pretty strange to modern ears, but maybe the underlying point was that it isn't possible to statically know how much stack size would be required. I suppose it wouldn't have been obvious then that if you fudge the issue…
Contemporary books (incl. TAoCP Vol. 1 IIRC) don’t place return addresses on a stack or in a register at all: you’re generally told to modify the operand of the jump instruction at the end of the procedure you want to call then jump to its entry point. It took a while before reentrancy was even recognized as a possibility, let alone used (by humans or compilers) by default.
I remember reading that the call stack was invented as an implementation device for recursion as introduced in Algol, but I can’t recall how that claim was sourced.
Re: Understanding thread stack sizes and how Alpine is different
#34Yeah, it sucks that programs crash on your system, but this is the way of things: The popular systems get targeted and tested in-depth, the less popular systems not so much. This is NOT the developer's fault; this is pragmatism.
And so the mountain must come to Mohamed. Increase Alpine's default stack size to something more in-line with the big boys.
Re: Understanding thread stack sizes and how Alpine is different
#35I'm annoyed by the fact that I have to visit "new" reddit to be able to accept cookies, and then go back to the old design. This is on desktop btw.
Re: Understanding thread stack sizes and how Alpine is different
#36> As most threads only need a small amount of stack memory, other platforms use smaller limits, such as OpenBSD using only 64 KiB and Alpine using at most 128 KiB by default.
By your own table, OpenBSD uses 512 KiB unless you're on an ancient version. Among the listed, Alpine is the lone outlier.
Re: Understanding thread stack sizes and how Alpine is different
#37Stop being cringe and adopt the same stack size as everyone else. Oh my god. What on earth are you saving?
IMO: it's nice to have weird platforms. I've caught lurking UDB and memory corruption in my programs by trying to run them on weird OSes.
There is no UDB or memory corruption exceeding the stack size. It means your platform is too small to run the program. Of course, Alpine doesn't run on platforms that are too small, they just make nonsensical changes like these that cause incompatibilities but have zero benefits.
Re: Understanding thread stack sizes and how Alpine is different
#38This is one of the reasons why I'm no longer using Alpine as a base in Docker images. I ran into this limit specifically with node-sass. But in general, the difference in image size is negligible because of shared layers, and I just don't think enough testing happens on Alpine / musl in any given stack. Even if your app runtime is tested this way, how many dependencies are? Come to think of it, I'm not even sure why…
It took some time before Ubuntu and Debian offered official slim containers... Before that, many programs in containers defaulted to Ubuntu or Debian, and it was 600MB to run something like Nginx or Apache, while alpine was 40MB
Re: Understanding thread stack sizes and how Alpine is different
#39Yeah, it sucks that programs crash on your system, but this is the way of things: The popular systems get targeted and tested in-depth, the less popular systems not so much. This is NOT the developer's fault; this is pragmatism . And so the mountain must come to Mohamed. Increase Alpine's default stack size to something more in-line with the big boys.
I would at least make it equal to MacOS, another very popular target where things are tested a lot. That’s 512KiB. 128 is teeny.
Re: Understanding thread stack sizes and how Alpine is different
#40Earlier quoted context omitted.
IMO: it's nice to have weird platforms. I've caught lurking UDB and memory corruption in my programs by trying to run them on weird OSes.
There is no UDB or memory corruption exceeding the stack size. It means your platform is too small to run the program. Of course, Alpine doesn't run on platforms that are too small, they just make nonsensical changes like these that cause incompatibilities but have zero benefits.
https://github.com/yaegashi/muslstack seems to indicate the limit is coming from musl (the libc) rather than Alpine, which may legitimately have a hope of running on small platforms.