[go-nuts] Re: slog default logger: replace and then revert

There's some interaction between setup of `log` and `slog` that is not revertible. Before `slog.SetDefault`, it's sort of the case that the `log` package's default resource is the destination for all global/default/standard logging (from `slog` or `log`). The mechanism is a little aggressive, e

[go-nuts] Re: Assembler, ABI0 frame & stack growth

piątek, 18 kwietnia 2025 o 00:10:02 UTC+2 Keith Randall napisał(a): On Thursday, April 17, 2025 at 11:50:18 AM UTC-7 Wojciech Kaczmarek wrote: Hi Gophers, I am experimenting with assembler, ABI0 and stuff. While I was learning the ABI0 frame structure from disassembled code, I noticed that th

[go-nuts] Re: slog default logger: replace and then revert

Sorry for spam, quick clarification: where I said "there is a slog handler that outputs via a resource managed by the log function" that's a bit jumbled, I intended to say "resource managed by the log package". On Thursday, April 17, 2025 at 4:21:17 PM UTC-7 Andrew Harris wrote: > There's some i

RE: [go-nuts] Should os.WriteFile call Sync()?

I'm sorry you experienced data loss here, but I don't think Go is remiss. The only thing in the entire API that refers to stable storage is the Sync call; on a correctly-behaving system you do not ever need to call Sync. It is only needed if you are protecting against an incorrectly-behaving sys

Re: [go-nuts] Should os.WriteFile call Sync()?

> Which is why you need full fsync- which is coordinated all the way down I don't understand this reply; file.Sync() does fsync syscall on POSIX (and with F_FULLFSYNC on macOS). Yes it's slower, but it's not really documented that it might be necessary. (It did cause us trouble in reality when th

[go-nuts] Assembler, ABI0 frame & stack growth

Hi Gophers, I am experimenting with assembler, ABI0 and stuff. While I was learning the ABI0 frame structure from disassembled code, I noticed that the stack check happens before subtracting from RSP (I'm on arm64, but the same applies to SP on amd64, I mean the hardware register ofc). Then,

[go-nuts] slog default logger: replace and then revert

Dear all, I thought I can temporarily replace the slog default logger and eventually revert to the previous one. But this seems not to be possible: https://play.golang.com/p/OQbgGm_DRLY Can someone explain, what is happening and how I can achieve my goal? Chris -- You received this message bec

Re: [go-nuts] Should os.WriteFile call Sync()?

Also, the real world edge case you are referring to is only (almost always) a hard system kernel crash - anything else and it will be written to disk. Also, even if it it written to disk you might still have a failure - which is can be mitigated with with redundant/raid storage. Anyway, the option

Re: [go-nuts] Should os.WriteFile call Sync()?

Even if the OS writes it to disk there is the possibility of failure due to lazy writes by the drive itself. Which is why you need full fsync- which is coordinated all the way down. It is also many orders of magnitude slower. See this for performance difference details https://github.com/robaho/cpp