6 ms·
Wtf?! https://github.com/egladman/herodotus/blob/master/server.js#L37 https://github.com/egladman/herodotus/blob/master/server.js#... How can a developer be t
by SFjulie1 11y ago
Wtf?!
https://github.com/egladman/herodotus/blob/master/server.js#L37 https://github.com/egladman/herodotus/blob/master/server.js#...
How can a developer be that stupid?
file.write is atomic (guaranteed to "work") for PIPE_BUF (posix) octects ~ 16ko at most.
JSON is guaranteed to be unparsable if the file is truncated of the last chars (it is not very resilient).
Hence the write may corrupt your WHOLE log if a non recuperable failure happens or the code is interrupted.
The code DOES not use fixed size allocation ... thus is can crash randomly because of SEGFAULT in the middle of the writing.
The history will take cumulative size in memory.
This coding attitude highers the probability of this failure to happen BY DESIGN.
Is it that complex to FIRST write the file, and THEN atomically rename the new file to the old file at worst (resulting only in losing the current session, but not the whole history).
If your log are that precious, why would you not take extra care about protecting them?
This code makes me want to puke.
On the other hand, it is representative of the reason why I am disenchanted by modern coding standards.
- readme 11y agoIt's too bad you have such a poor attitude since you're obviously skilled.
- SFjulie1 11y agoIt reminds me bad cooks with cockroaches in their kitchen telling Gordon Ramsay that he is a pedantic asshole. Sometimes some practice reflect the total lack of potential professionalism. Before making money out of food, you care about not poisoning your customers. And any cook refusing to respect hygiene rules should be barred from kitchen by any sane managers, because there is nothing you can do with them. Same goes with some coders.
- SFJulie2 11y agoHey Julie, Do you live in a state of perpetual nausea? Because there is so much code out there like this...I fear it could overwhelm your life to worry about it. I think the best we can do is just fix the stuff we want to use and ignore the rest..
- SFjulie1 11y agoNot Julie. It is a pun in french. Julie is like calling me Hanni when my real name is more like Hanniballs. And I still have my balls. So keep it julie1. But I guess you may lack of context to get it right, as for the rest of your comment. ;)
- egladman 11y agoI'll see to it that this is fixed.
- SFjulie1 11y agoOhla. You have to rewrite it entirely. Logs should only be built by chunking at the end of the file atomic write of data in at most PIPE_BUF with an "atom" based on this quantity of data. You are free to do whatever serialization inside this constraint as long as a missing chunk cannot corrupt the whole file. (That is the reason I switch off from systemd that stopped respecting this rule.) For your logger to work in a "safe fashion" it has to be designed like an asynchronous HW driver. A part consuming the logs from IRC, that pushes chunks in circular buffer ring of N fixed size data for which buffer overflow HAVE to be checked (per chunk size and for N) (the bottom half). And a driver that is signaled "asynchronuously" to write the chunks into a file when ready. The critical part (writer) should almost be a one liner to avoid interruption and be written in an overly defensive paranoid fashion. You should have a cursor for the writer and the reader on the circular buffer ring and should always check that the consumer does not overrun the writer. Hence the writers' code should be designed to be asymmetrically faster than the reader. It requires IPC or messaging to coordinate both reader and writer. Most people do it in multithreading, I do it with multiprocessing because it is simpler. You should understand that you have thus a Single Point Of Failure (the file) and that because of all this your software will have a domain in which it will fail (if you want to multiply the reader to distribute the load for the consumer to 'scale up'). The file has to be opened with exclusive access. The code must have a "catch all I can" to be able to unlock the file if ever something bad happens and at startup the code should check it can open the file. (atexit callbacks and every "recoverable" interruptions sent by the OS). file.seek is your friend. You should not use any dynamic allocation to make it more robust (yes preallocating fixed memory size with "char circular_ring[N * MAX_SIZE]") Where N and MAX_SIZE are fixed. Well. It requires a complete rewrite for this code to not create a risk for your users. Your code is like full of hidden landmine by lack of design. And you know what? It used to be standard knowledge for introduction to CS for scientific. You know why? Because no users of computers like to lose their precious data made during a very long measurement spilling huge amount of data and costing a lot of resources. (like gold, helium, molybden, electricity, time, wages of qualified operators....) It seems like coders do not care of their users, like a builder thinking it is reasonnable to build 50 store buildings on quicksands because people only judges builder by the look of their creation.
- dang 11y ago> How can a developer be that stupid? [...] This code makes me want to puke. This comment breaks the HN guidelines so badly that we could put it on a poster of how never to behave here. It doesn't matter how right you are if you express it this abusively. Since you've done this more than once before, I've banned your account. If you don't want it to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that your comments will be civil in the future. All: In addition to https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html, please know that HN has extra rules at https://news.ycombinator.com/showhn.html https://news.ycombinator.com/showhn.html to guide the discussion of new work. The parent comment breaks every one of them.