Haiku Seeing Better Rust Support Following Important Fix

[phoronix]

Phoronix: Haiku Seeing Better Rust Support Following Important Fix

Following a summer quest for figuring out a pesky thread issue with Rust, a fix has been merged into the BeOS-inspired Haiku kernel for one less patch to worry about with getting this popular programming language running well...

http://www.phoronix.com/scan.php?page=news_item&px=Haiku-Rust-Thread-Fix

[skeevy420]

It had to be infuriatingly annoying doing all that work and testing to figure out the problem to end up finding a setting that either needs the values tweaked or doesn't belong there at all. I can see how 32 threads as a limit made sense in the old days where 2 physical CPUs would net you 6c12t max, but now single slot CPUs with 64 and 128 threads are common and compilers and programs can and will utilize stupid high amounts of threads when possible. With CPUs getting more and more threads every generation, removing that hard limit is probably the simplest and easiest way forward.

[chocolate]

It had to be infuriatingly annoying doing all that work and testing to figure out the problem to end up finding a setting that either needs the values tweaked or doesn't belong there at all. I can see how 32 threads as a limit made sense in the old days where 2 physical CPUs would net you 6c12t max, but now single slot CPUs with 64 and 128 threads are common and compilers and programs can and will utilize stupid high amounts of threads when possible. With CPUs getting more and more threads every generation, removing that hard limit is probably the simplest and easiest way forward.

AFAIU it wasn't about hardware limitations, but a way to prevent developers from abusing pthreads, see "Finalizing the Solution" on the original Haiku blog post. They then talked about it and came to the conclusion that there are easier ways to interfere with the system's stability, hence why they chose to remove the limit on dead threads altogether.

Also, it seems like the developer had a fun and relaxing time while working on this during their summer vacation.

[skeevy420]

AFAIU it wasn't about hardware limitations, but a way to prevent developers from abusing pthreads, see "Finalizing the Solution" on the original Haiku blog post. They then talked about it and came to the conclusion that there are easier ways to interfere with the system's stability, hence why they chose to remove the limit on dead threads altogether.

Also, it seems like the developer had a fun and relaxing time while working on this during their summer vacation.

Yeah, that's why I called it the easiest way forward. I figure the harder way would have some sort of dynamic limit based on the number of threads of the underlying CPU used.

I've been there too. I think most Phoronix regulars have been there at one point in time. I totally get the fun of debugging a problem...and then finding a magic bullet setting you didn't know about when you started that also solves your problem can be all rolled into one. I should have called it infuriatingly, annoyingly, happy.

[bug77]

Yeah, that's why I called it the easiest way forward. I figure the harder way would have some sort of dynamic limit based on the number of threads of the underlying CPU used.

I've been there too. I think most Phoronix regulars have been there at one point in time. I totally get the fun of debugging a problem...and then finding a magic bullet setting you didn't know about when you started that also solves your problem can be all rolled into one. I should have called it infuriatingly, annoyingly, happy.

Tru dat. Most solutions to problems that take you weeks to investigate turn out to be one-liners.