Critical section was IIRC built on top of windows manual/auto reset events which are a different primitive useful for more than just mutex but without the userspace coordination aspect (32 bit value) of futexes.
What is the point of the intent entry at all? It seems like operations are only durable after the completion record is written so the intent record seems to serve no purpose (unless it is say much larger).
I use Atuin and like it a lot, and sync history across hosts.
However, the fuzzy search in Atuin is worse than fzf, which was a downgrade. It just has less effective heuristics/scoring, e.g. it might find the individual letters of a short command scattered in a command that had a long base64 input or something.
An absolute requirement in Japan if you are more than a few minutes late in Japan. A thirty minute delay during morning rush hour used to have train staff with a stack of papers handing them out to everyone going out of the gate kiosk. I used to get them after any delay at all on my commute.
I assume now annoying bosses can check online, but it's Japan so an old person in charge might ask for the paper slip as well just in case you overslept when you were in a nearby business hotel after a rather awful stint of over time the night before.
I imagine (I don't live in the Chicagoland area, so guessing here, perhaps someone from the 'burbs there can chime in) it's a note from the CTA saying the train was delayed so you can limit your negative exposure when you boss wants to know why you're two hours late.
Which is actually much more than NYC does. Although that has its advantages as well. The linked fortune[0] (actually an excerpt from a NYT 'Metropolitan Diary'[1] piece ca. 1980) details this:
I for one cannot protest the recent M.T.A. fare hike and the accompanying
promises that this would in no way improve service. For the transit system,
as it now operates, has hidden advantages that can't be measured in monetary
terms.
Personally, I feel that it is well worth 75 cents or even $1 to have that
unimpeachable excuse whenever I am late to anything: "I came by subway."
Those four words have such magic in them that if Godot should someday show up
and mumble them, any audience would instantly understand his long delay.
I shudder to imagine the working relationship where that’s relevant.
But I very much appreciate the advantages you point out. I felt a little sense of loss when, on work in that city, I noticed that some degree of cellular service had reached the stations…
Wow. TIL. I'm a life-long NYer and never knew that.
Thanks!
>But I very much appreciate the advantages you point out. I felt a little sense of loss when, on work in that city, I noticed that some degree of cellular service had reached the stations…
If it makes you feel any better, such signal isn't very common, although the MTA is looking to change that[0]
CTA never did that; I don’t think they could if the wanted to.
Metra did it, I’m 99.9% sure they stopped years ago. But yeah, there would be a person at the platform when the train arrived downtown with a piece of paper saying that the train was delayed. A late slip.
Nowadays, you have real-time location tracking of the train. If it’s late, you can tell your employer what train you’re on and they could verify it. At least to a better degree than with the late slips. Still not perfect. But if you’ve got an employer that would want to verify such things, you’ve got worse problems.
>CTA never did that; I don’t think they could if the wanted to.
>Metra did it, I’m 99.9% sure they stopped years ago. But yeah, there would be a person at the platform when the train arrived downtown with a piece of paper saying that the train was delayed. A late slip.
Thanks for the clarification. I wasn't 100% sure about who the relevant agency was (as I mentioned, I don't live there -- although I do have family that does).
>Nowadays, you have real-time location tracking of the train. If it’s late, you can tell your employer what train you’re on and they could verify it. At least to a better degree than with the late slips. Still not perfect. But if you’ve got an employer that would want to verify such things, you’ve got worse problems.
A fair point, but there are some circumstances where both employee and employer may need to justify/document such circumstances -- but on the whole, you're spot on.
>A fair point, but there are some circumstances where both employee and employer may need to justify/document such circumstances -- but on the whole, you're spot on.
I think we should also make it common practice to share grocery lists with your employer, as well as the date and time of sexual acts. This is even more justifiable than the status of the train that takes you to work.
I mean, trains are late not often enough to make any significant difference. Whereas unhealthy diet, or say, sleepless nights of lovemaking, can dramatically affect a worker's productivity almost permanently.
>I think we should also make it common practice to share grocery lists with your employer, as well as the date and time of sexual acts. This is even more justifiable than the status of the train that takes you to work.
>I mean, trains are late not often enough to make any significant difference. Whereas unhealthy diet, or say, sleepless nights of lovemaking, can dramatically affect a worker's productivity almost permanently.
You misunderstand me completely -- is that on purpose, are you only focused on your situation and assume no other situation could possible exist?
Or are you just dumb?
Contracts that an organization may have with their customers may require that personnel be onsite at particular times, with the caveat that penalties in the contract may be lessened or eliminated if the lapse was an event outside the contractor's control.
In such situations, it can be important (assuming you want to get paid) to be able to document such events.
Parent's comment was the sarcastic observation that if employers ought to be able to verify workers' commutes, they could justifiably also want to monitor other aspects of workers' lives outside of work that have a significant impact on productivity.
The argument is valid whilst being entirely dystopian. There is a level of trust, or at least tolerance, between employer and employee that must be accommodated in society; otherwise there is no choice but brutally invasive surveillance of all workers.
>Parent's comment was the sarcastic observation that if employers ought to be able to verify workers' commutes, they could justifiably also want to monitor other aspects of workers' lives outside of work that have a significant impact on productivity.
Was it? Where did you get that idea?
Based on their posting history (and I did check before replying just to make sure I wasn't misunderstanding), that they were absolutely serious is most likely.
>The argument is valid whilst being entirely dystopian. There is a level of trust, or at least tolerance, between employer and employee that must be accommodated in society; otherwise there is no choice but brutally invasive surveillance of all workers.
Absolutely, and I never said anything different. In fact, the bit GP quoted and replied to was:
>A fair point, but there are some circumstances where both employee and
employer may need to justify/document such circumstances -- but on the whole,
you're spot on.
Their response was orthogonal to my point. Which made me wonder why. And so I asked.
Keep an eye on my userid. If you don't like what I have to say, I strongly suggest you don't read my comments.
> Based on their posting history (and I did check before replying just to make sure I wasn't misunderstanding), that they were absolutely serious is most likely.
I, on the other hand, didn't check their posting history, and it looks like you might be right... Poe's Law strikes in reverse, perhaps!
Uncontended CAS without carried dependendies on the result (almost always the case in this use case) are similar in performace to atomic add on most platforms.
The CAS is the price they pay for contention detection, though it would be interesting to consider solutions which usually use unconditional atomics with only the occasional CAS in order to check contention, or which relied on some other contention detection approach (e.g., doing a second read to detect when the value incremented by more than your own increment).
The solution looks reasonable to me given the constraints.
Part of my point was that "check for contention" is often a silly thing to do in the first place, when you can just avoid it entirely (and with simpler code too).
Admittedly, Java is fundamentally incapable of half of the solutions, but making a simple bump allocator (called once per statistic at startup) over per-thread arrays is still possible.
Yeah exactly, and this is a commonly used trick in concurrent data structures in general. The Java implemenation has the additional twist that they don't use a fixed number of "slots" but rather start at 1 and use CAS failures as a mechanism to detect contention and then grow the number of slots until there are no longer CAS failures.
For network receive, I was assuming kernel-bypass sockets, not kernel sockets.
`bytes` can give you "ring-buffer-like" one-copy kernel-socket receive by e.g. using the Buf as the target for scheduling io_uring read/recv into.
Also, RDMA is technically networking! (Though I think all the Rust RDMA libraries already provide ADTs that work like Buf/MutBuf, rather than just saying "here's some network-shared memory, build your own ADT on top.")
Thanks, you mention explicitly kernel networking right below about the send path:
> before flinging them at the kernel as [vectors of] large, contiguous DMA requests, without having to stop to allocate
So I had assumed you were taking about kernel networking elsewhere as well.
BTW, on the kernel send path, there is again a copy, contiguous or not, regardless of what API you use.
When using kernel networking I don't think contiguity matters as you suggest, as there is always a copy. Furthermore "contiguous" in userspace doesn't correspond to contiguous in physical address space so in any case the hardware is just often going to see a userspace buffer as a series of discontiguous pages anyway: that's what happens with direct IO disk writes, which _are_ zero copy (huge pages helps).
