Hacker News new | ask | show | jobs
by cperciva 998 days ago
DragonFly and FreeBSD have radically different ideas on how multithreading should work. (Understatement of the century right there!)

To elaborate for people who don't know the history: Disagreement about how multithreading should work are why Matt got booted from the FreeBSD project and started DragonFly.
1 comments
darkhelmet 998 days ago
It's not that simple. Disagreements are one thing, but the real reason was the conflict and drama that happened when things didn't go his way. The threading approach just happened to be a really good trigger for those conflicts.

Conflicting personalities makes resolving technical disagreements so much harder.

link
cperciva 998 days ago
I was being euphemistic. It was a "doesn't play well with others" issue, but it came to the fore with SMP.
link
bch 998 days ago
Playing well obviously important (and I wasn’t involved, have no other insight), but do you know if the poor showing for fbsd 5.x correspond w the disagreements?
link
cperciva 998 days ago
FreeBSD 5.x was a very stressful time -- bringing full SMP to the entire kernel was a massive technical challenge, and it didn't help that a lot of the people who were expecting to work on it lost their jobs during the dot com crash.

5.x was a poor vintage because making the kernel SMP was hard, and social issues became problematic because SMP was hard, but Matt's departure was neither the result or cause of FreeBSD 5.x having issues.

link
tiffanyh 998 days ago
In hindsight, with it being now 20 years later, which approach to SMP do you think was the better technical choice?

The FreeBSD model or DragonflyBSD approach?

link
cperciva 997 days ago
Assuming "the DragonflyBSD approach" is the same as when it forked 20 years ago: FreeBSD's approach was definitely the right one, for two reasons.

First, adding locking is fundamentally easier to get right than rewriting everything into a message-passing model. It took ~5 years to get SMP right in FreeBSD (from when 4.0 was released to when 6.0 was released) but it would have taken double that to get things equally stable and performant with the more intrusive redesign Matt wanted to go with.

Second, pretty much everyone else went with the same locking approach in the end -- which has resulted in CPUs being optimized for that. Lock latencies dropped dramatically with microarchitectural changes between ~2005 and ~2015.

As a theoretical concept, I love the idea behind Dragonfly, but it simply wasn't practical in the real world.

link