Viewing profile — DblPlusUngood
DblPlusUngood
HN member- Joined
- Wed, May 06, 2015, 12:16 PM UTC
- HN karma
- 240
- Public activity
- 63 items
- HN profile
- View on Hacker News ↗
About DblPlusUngood
No profile information was provided.
Recent public activity
-
comment
Comment #29134777
Yes.
-
comment
Comment #27399099
In some cases, yes (if there are other runnable threads on this CPU's queue).
-
comment
Comment #27397659
A better example: a page fault for a non-present page.
-
comment
Comment #21414683
Don't forget gltron!
-
comment
Comment #19923681
You are absolutely right. They are used everywhere in the Linux, OpenBSD, and FreeBSD kernels, and likely many other kernels. Replacing large linked lists with arrays is rarely an …
-
comment
Comment #19749916
> I don't see how it could. Kernel data structures don't go on pagecache pages. Kernel data structures could end up on a pagecache page: all it takes is a reference counting bug an…
-
comment
Comment #19747159
OpenBSD's choice is arguably reasonable, given their prioritization of security, since it reduces opportunities for user programs to corrupt kernel memory. What is the problem with…
-
comment
Comment #19740062
What coherence is lacking? OpenBSD supports msync(2), which is the only POSIX mechanism I know of for ensuring coherency between read(2) and shared file mappings. Otherwise relying…
-
comment
Comment #19643538
OpenSSH does have confirmation: use the '-c' switch to ssh-add. https://man.openbsd.org/ssh-add
-
comment
Comment #19623666
Is recovery of a shared memory queue after one of the workers crashes even possible, in general? (what if the worker crashed before releasing a lock?)
- comment
-
comment
Comment #19490539
Sounds like a fun project! Isn't seL4's multicore support either unverified or limited (i.e. shared memory is forbidden)? Is your platform single-threaded then?
-
comment
Comment #19347811
Yes. In theory, maybe it's useful to have more flexibility to trade-off durability for performance (smaller quorum size hopefully reduces deciding latency [unless your small quorum…
-
comment
Comment #19143424
Instead of an ad hominem, please clearly explain the main way that the example Go code is less safe than the C example code.
-
comment
Comment #19115310
This is a great point. Jargon can be really intimidating and make the simplest statements impossible to understand for the unfamiliar. But is often trivial to learn with a little s…
-
comment
Comment #19055757
A particularly tricky task with GNU make is automatically adding target dependencies on header files and handling updates to them (gcc's -M and -MMD switches). It would be great if…
-
comment
Comment #18612870
How are GCs not compatible with bounded memory use? Though many GCs size allocation arenas proportionally to the live data, there is no fundamental reason why the allocation arenas…
-
comment
Comment #18607846
Well, for one thing, zig apparently has no built-in memory allocator?
-
comment
Comment #18316457
Turns out the x86 already has some bounds checking support; see chapter 17 in volume 1 of Intel's developer manuals and the BOUND and BND* instructions.
-
comment
Comment #18252460
> I love the BSDs and especially OpenBSD for their attention to manpages. It's the main reason why I don't use Linux anymore unless I have to. I completely agree. The difference in…
-
comment
Comment #18173869
1. I wouldn't say we are skeptical of Rust, I'm sure it could be made to work well and we would love to see such a Rust kernel! I do wonder whether it would be harder to implement …
-
comment
Comment #18173817
Hah, I am Cody and I'm not related to Dave Cutler (as far as I know!).
-
comment
Comment #18172318
Concerning your first question, that experiment is not intended to measure the cost of GC, which can be made small by trading memory. The point of this experiment is to measure the…
-
comment
Comment #18171742
Well that was fast! I'm an author of this paper and would be happy to answer questions.
-
comment
Comment #17756920
Different Linux kernel config options, probably. Different options can drastically affect performance.