In https://github.com/alexhultman/uWebSockets/blob/master/src/u...
What's the deal with
delete [] (char *) head;
where `head` is of type `struct Message` ? Is this some kind of performance trick ?... Otherwise it looks kind of suspicious..
What's the deal with
delete [] (char *) head;
where `head` is of type `struct Message` ? Is this some kind of performance trick ?... Otherwise it looks kind of suspicious..
EDIT: Specifically I'm referring to the usage of raw pointers, unchecked pointer arithmetic, goto for flow control and raw new/delete calls. The author says they have run tests under valgrind, but that doesn't say anything unless the inputs were malicious. Ideally it should be compiled with ASAN and run under something like afl-fuzz.
Also - why do you take a libuv dependency - then use uv_poll_t directly with raw send/recv calls instead of using uv's provided TCP primitives?
This implementation is way, way more lightweight. And it assumes that the buffer being queued has a struct Message in its head, so it doesn't have to allocate a node - one memory allocation is therefore skipped.
Thanks for giving your infinite enlightenment, after looking at my code for 10 minutes. I guess your 10 minutes of reading the code is infinitely much more valuable than my 3 months work on it?
Get over yourself.
The sarcasm, childish comments, and resorting to insults the second someone criticizes your code isn't giving me any hope that you can competently maintain a project like this.
Take a look over the HN Guidelines [1] and the "Approach to comments"[2] sections of the site.
It's a valid question (that i think you did answer, but not very well). Dropping to very unsafe "lower levels" should only be done when absolutely necessary as a single mistake here could cause massive security issues.
When people attack your code, it isn't an attack on you. It makes your code better. It's one of the downsides to releasing any opinionated project (and many good projects are opinionated).
For my part, I won't use software written by someone who doesn't either refute criticism or use it to improve code, and I'm not satisfied you're doing either of those.
Thank you, you will be missed. I don't know what to do without you.
When reading your comments and code on the web, it seems like you're really an awesome dev, but you give in to hate comments by such people too easily.
But reading the comments in this thread this has gone overboard....to the point I, as a casual observer, had to say something.
I agree, "clearly written by someone who doesn't know the language well", _IS_ a direct attack on the developer and not the code. And I couldn't comprehend the mental gymnastics it would take to explain otherwise.
There is a major difference between:
"Why did you implement your own Queue here?" and "This guy doesn't understand C++. Don't use his code."
Don't let them win by giving into replying with a "Redditor" form of rebuttal filled with snark.
I don't care how good your code/framework is if you blow up on just a minor bit of criticism. This is a great example where some comments in code could help teach people who don't know better.
Long gone are the days where the solo programmer could make important software without interacting with the rest of the outside world. Knowing when to check your ego at the door is just as important as getting the technical bits right.
Also, your work looks good. I want to use it.
The comment that provoked you was rude and dismissive and the sort of thing we ask people not to post. That said, the guidelines here ask you to remain civil even when someone else is uncivil and/or wrong. That's an important rule that we all have to abide by—though it's a challenge, especially when one's own work is being discussed—because otherwise the discussion quality will rapidly deteriorate.
So please either make substantive neutral replies if you can, or don't post anything until you can.
But without all that you would lose performance which seems to be the main goal of this project.
Every decision made, has been made from a performance perspective.
I do not know what the overhead of uv_poll_t is compared to epoll/kqueue but I think it's a good balance to depend on libuv in this case, and since we need to integrate with Node.js it is kind of required.
I would much rather use mTCP to further improve the performance but then this project would not be as relevant to most developers. Performance & relevance is key - it can be optimized further by using mTCP and such.