Resources want to be free!
-
@pie_flavor said in UI Bites:
@Tsaukpaetra Engaging in Nintendo piracy, I see.
It's almost fucking 2020. If Nintendo is somehow making a profit from original Wii sales on a console they've all but claimed dead, I'll close my sockets.
-
@Tsaukpaetra said in UI Bites:
I'll close my sockets.
You should always close your sockets properly when you're done with them. Don't just reset them and let the other peer rot.
-
@PleegWat I don't remember how often I've had to explain that to newbies looking at tcp dumps. No, those resets are not errors. They're just IE being a dick.
-
Don't just reset them and let the other peer rot.
I should poke that one dude I saw who did that and relied on Windows to clean up when the application exited.
-
@Tsaukpaetra said in UI Bites:
Don't just reset them and let the other peer rot.
I should poke that one dude I saw who did that and relied on Windows to clean up when the application exited.
Raymond Chen?
-
@levicki said in UI Bites:
Raymond Chen?
I am sure people using garbage collected languages know off the top of their head which resources in Windows apps should be released and which can be left to the runtime and OS to clean up.
Do I sense sarcasm? Because if it's sarcasm, then it's very misguided. An average C# developer would have a much better shot at this question than an average C++ developer.
Thanks for the downvote! That way I know I've done well.
-
@levicki said in UI Bites:
Actually, if anything, C# devs have much less chance to know Win32
But that wasn't the question!
Managed languages only manage memory - everything else is still managed manually. In modern C#, it means
usingstatement. In a typical shutdown procedure, you return from every function you called until you return from entry point, finalizing all theusinged resources. This is quite suboptimal, because not all resources have to be released manually on exit, but at least memory is forgotten about because it's managed by runtime. Compare to C++, where everything is RAII and so it works like described above - except memory is RAII too, so it also deallocates all the individual allocations right before exiting the program.So by pure chance, an average C# dev would happen to accidentally do a slightly more right thing than an average C++ dev in this one regard.
-
@levicki said in UI Bites:
But that wasn't the question!
Sure it was, you personally suggested that Raymond Chen himself, the old school developer with knowledge of assembler, C, Win32 API and all their quirks is "that one dude I saw who did that and relied on Windows to clean up when application exited". You implied by your joke that Raymond Chen is incompetent programmer and then you made it worse by suggesting an average C# developer might know better.
This is all so wrong I don't even know where to start. Everything that you could possibly get the wrong way, you've got the wrong way. First of all, no, I've never even as much as suggested that Raymond Chen might be in any way lacking competence. Quite the opposite - it's because of his incredibly vast knowledge of everything programming from top to bottom that he can with certainty state that cleaning up some resource properly isn't necessary on shutdown. Most programmers don't even think of such questions.
Second. If you actually read my posts instead of listening to the abridged version narrated by your shoulder aliens, you'd notice I never said an average C# developer knows about any of this stuff. Again, the opposite is true - I tried to make as clear as possible that the fact that average C# developer does it better than average C++ developer is a lucky accident.
Third. I never compared Raymond Chen to average C# developer. I compared average C++ developer to average C# developer. As a direct reply to your mockery of programmers using managed languages. Yes, most C# programmers have no idea which resources are allowef to leak on shutdown and which aren't. News flash: most of C++ programmers don't know either!
Seriously, it's like you didn't even read my post, just seen the avatar and immediately assumed the dumbest things.
Managed languages only manage memory - everything else is still managed manually. In modern C#, it means using statement.
And managed objects are not memory (with methods which include constructors and destructors and which can contain unmanaged resources)?
Is file handle a memory? Network connection? Mutex lock? Do you even know why finalizers exist in the first place?
Are you saying that a class derived from C# Form must be used with
usingkeyword in order to clean up its underlyingHWND / HFONT / HICONand any other unmanaged resources it might have?No I'm not you dumb fuck.
Because that's what I had in mind when I said C# devs will have less chance knowing what must be released and what the OS will handle itself, since the language is abstracting that for them.
No it's not you dumb fuck. The runtime only abstracts away memory. Everything else is still manual. By manual, I mean finalizers that get called either directly in code, automatically at the end of
usingblock, or by GC on collection. Which in the specific case we're talking about - exiting application - has the same effect as RAII: finalizers get called on everything finalizable. But because you don't need finalizer to release memory, it doesn't get done until process exit. Which leads to faster shutdown than in C++ where every allocation gets freed individually due to RAII. Most C# devs don't even think about it, but still end up doing the slightly more right thing.Compare to C++, where everything is RAII and so it works like described above - except memory is RAII too, so it also deallocates all the individual allocations right before exiting the program.
Not sure what you mean by memory is RAII
Do you even know what RAII is? Seriously, when was the last time you wrote any C++ code? 2004? How about you actually learn how C++ is written in this decade before commenting on it?
Btw, you didn't answer my question.
If you read the very first sentence of my post (the one you quoted in the very beginning), you'd know why.
-
@Gąska Almost all resources do not need to be explicitly cleaned up on process shutdown. The exceptions all relate to external things that have non-trivial shutdown requirements. Some database connections are in this category, as is the display (when running full screen), and TCP sockets probably ought to be shut down cleanly too. The OS will eventually manage to clean most things up, and purely local-memory-based resources can be handled entirely that way (inter-process shared memory can't, but that's a tiny minority).
-
@dkf you forgot files. The most common external resource with non-trivial shutdown is writable files. Not per se, but whatever library you're using for file access, it's basically guaranteed it has some internal write buffer that needs flushed on close, and failing to do so can result in data corruption. Also, it might be because you're in different niche, but it feels like you're seriously downplaying how often programmers have to (indirectly) deal with TCP connections.
-
Someone apparently disagrees you need to flush write buffers before returning file handle to the OS. Oh well
-
Someone apparently disagrees you need to flush write buffers before returning file handle to the OS. Oh well
why bother flushing it if as part of the kernel closing the handle it'll flush it for you?just seems.....Actually, wait. I don't want to get involved in this.... I said nothing. Nothing, do you hear?
-
-
@levicki said in UI Bites:
@Gąska You gonna get RSI from clicking that button
Just like you said you didn’t downvote him, I doubt he downvoted you.
I’m going to assume someone (actually at least 2 people) are just annoyed about this discussion in general.
-
This is the UI Bites thread, right? What's with this weird UI for the link embeds?
-
Actually, wait. I don't want to get involved in this....
Sadly, I lack jurisdiction to do anythin about it, so willful ignorance is my only option!
-
What's with this weird UI for the link embeds?
The wordpress site is intentionally linking to a blank image of that size for some reason.
-
@levicki said in UI Bites:
Everything that you could possibly get the wrong way, you've got the wrong way.
That's exactly what happens when you read my posts, no?
I refuse to believe it is physically possible to be as idiotic as you appear to be, so yes, I really really hope I've got something wrong and you don't actually think that I ever meant to say anything negative about Raymond Chen or that an average C++ developer actually knows which resources are safe to not destroy on process exit.
I tried to make as clear as possible that the fact that average C# developer does it better than average C++ developer is a lucky accident.
It's the effect of the language doing the hand-holding. If it wasn't, there would be no lucky accident.
Nope. Not at all. There's many ways the hand-holding could not result in this behavior. As well as accidentally create this behavior without any hand-holding whatsoever.
ShittyAverage C devs do that all the time, and so did C++ devs before proliferation of smart pointers.The runtime only abstracts away memory. Everything else is still manual.
The runtime library abstracts a shit ton of Win32 unmanaged resources in a way that an average C# dev doesn't even know how any of it works.
In the same way C++ standard library abstracts all that shit away too - so it's a tie. What isn't a tie is how memory gets freed.
By manual, I mean finalizers that get called either directly in code, automatically at the end of using block, or by GC on collection.
Eh... let's not go down that rabbit hole please...
Okay, I admit I confused finalizers with IDisposable. Although I must point out that everything I was wrong about, doesn't matter for this discussion because we're talking about skipping unnecessary cleanup, not ensuring necessary cleanup.
Which leads to faster shutdown than in C++ where every allocation gets freed individually due to RAII
If you mean objects then yes, destructors get called for each. But the beauty of C++ is that you can fallback to C and avoid objects
How many more times do I have to repeat that?
AVERAGE C++ DEVELOPERS
AVERAGE C++ DEVELOPERS
AVERAGE C++ DEVELOPERS
AVERAGE C++ DEVELOPERS
AVERAGE C++ DEVELOPERS
AVERAGE C++ DEVELOPERS
AVERAGE C++ DEVELOPERS
AVERAGE C++ DEVELOPERS
Someone apparently disagrees you need to flush write buffers before returning file handle to the OS
Khm...
FILE_FLAG_WRITE_THROUGH... khm...You still flush all your buffers in this case.
-
@levicki said in UI Bites:
@Gąska You gonna get RSI from clicking that button
Just like you said you didn’t downvote him, I doubt he downvoted you.
I’m going to assume someone (actually at least 2 people) are just annoyed about this discussion in general.Based on the upvotes you get - one of them is @Choonster?
It's not like I care really. I'm just doing a fun little detective game.
Edit: originally I indicted @loopback0 too, then I've noticed another upvote that doesn't fit.
-
@levicki said in UI Bites:
@Gąska You gonna get RSI from clicking that button
Just like you said you didn’t downvote him, I doubt he downvoted you.
I’m going to assume someone (actually at least 2 people) are just annoyed about this discussion in general.Based on the upvotes you get - one of them is @Choonster?
It's not like I care really. I'm just doing a fun little detective game.
Edit: originally I indicted @loopback0 too, then I've noticed another upvote that doesn't fit.
These arguments do get a bit tiring to read sometimes, but I don't downvote.
-
@dkf you forgot files. The most common external resource with non-trivial shutdown is writable files. Not per se, but whatever library you're using for file access, it's basically guaranteed it has some internal write buffer that needs flushed on close, and failing to do so can result in data corruption. Also, it might be because you're in different niche, but it feels like you're seriously downplaying how often programmers have to (indirectly) deal with TCP connections.
No, those are definitely examples where finalization is useful/vital. Nobody is saying otherwise. It's just that in most non-trivial code, those things are a very small proportion of all all objects in play.
The buffer flush case is actually so vital that it probably has it's own special mechanism inside the runtime so that flushes happen even on exits associated with (controlled) crashing. Exit handlers are tricky things, but really necessary. (Socket shutdown isn't as critical as that, and there are all sorts of other reasons that networking is tricky and why so much of it is on more of a best-effort basis only.)
-
Edit: originally I indicted @loopback0 too, then I've noticed another upvote that doesn't fit.
I just skipped the majority of it. Downvotes have nothing to do with me.
-
@levicki said in UI Bites:
@Gąska You gonna get RSI from clicking that button
Just like you said you didn’t downvote him, I doubt he downvoted you.
I’m going to assume someone (actually at least 2 people) are just annoyed about this discussion in general.Based on the upvotes you get - one of them is @Choonster?
It's not like I care really. I'm just doing a fun little detective game.
Edit: originally I indicted @loopback0 too, then I've noticed another upvote that doesn't fit.
I’d say (trollishly) that @Mason-Wheeler has regained control of his alt accounts, but he’s not involved in any of this.
-
@levicki said in UI Bites:
But the beauty of C++ is that you can fallback to C and avoid objects, and you will have even faster shutdown, especially if you don't bother to free anything because the OS will do it for you anyway.
Doing that too liberally will mean you cannot easily use valgrind to identify leaks.
-
It's not like I care really. I'm just doing a fun little detective game.
Guys, it's obviously @boomzilla, duh!
-
The buffer flush case is actually so vital that it probably has it's own special mechanism inside the runtime so that flushes happen even on exits associated with (controlled) crashing.
Nope. Unless you run in some baby crib environment that makes .NET look like deadly adventure, there will always be some fatal error scenarios that will have to skip destructors/finalizers and terminate process without flushing all the buffers - unless the programmer themselves ensures this doesn't happen.
-
@Choonster said in UI Bites:
These arguments do get a bit tiring to read sometimes, but I don't downvote.
@loopback0 said in UI Bites:
I just skipped the majority of it. Downvotes have nothing to do with me.
^This. I've just upvoted @topspin's post up to 12, but I didn't downvote any of the others; I just ignore them.
-
@levicki said in UI Bites:
Although I must point out that everything I was wrong about, doesn't matter
Saying this is quickly becoming your default defense when you are wrong about something, why don't you put it in your signature?
So classy of you to cut off the quote right before I explained why it doesn't matter for this particular discussion. How about you first show that the explanation is invalid, and then comment on my habits?
In the same way C++ standard library abstracts all that shit away too - so it's a tie.
C++ standard library doesn't have wrappers for windows and other UI controls, not to mention WinHTTP, so it's not a tie.
An average C++ developer does use additional libraries that wrap these for them, too. Look. Just because you are retarded and avoid convenience like fire doesn't mean everyone else is retarded too.
You still flush all your buffers in this case.
Not me -- the OS, if you specify that flag on open/create.
None of your buffers didn't flush. Therefore, you flush all your buffers. First order logic 101.
Regarding up/down votes, I would appreciate if people would only downvote things which are factually incorrect, not just those they don't agree with and vice versa.
Well, your posts are full of factually incorrect statements. So I guess you'll agree you deserved all of them.
-
Wow, if @levicki keeps this up, he's totally gonna make @Gąska blow a gąsket!
-
@boomzilla said in UI Bites:
Resources:
: https://what.thedailywtf.com/topic/26982/resources-want-to-be-freeWould have been funnier if you somehow forgot to unlock this thread.
-
Side note - when writing my last post, for a moment I wanted to say C++ programmers aren't masochists.
-
@Gąska said in Resources want to be free!:
By manual, I mean finalizers that get called either directly in code, automatically at the end of using block, or by GC on collection.
WRONG. The Dispose method gets called at the end of a using block, or directly in code [never by the GC] and the finalizer is called (if it exists) by the GC unless it has been explicitly supressed.
-
@TheCPUWizard yeah, yeah, I know, I know, I already admitted the mistake upthread. It is possible for someone to utterly fuck up implementing Dispose (especially when you're @levicki and ignore any and all green squigglies Visual Studio gives you - because there is a warning about fucking up implementing Dispose), but in general, if the process exits normally (by which I mean it doesn't exit abnormally, obviously), Dispose method (which I confused with finalizer) will get called eventually, one way or another. Which matches C++ behavior, because abnormal termination doesn't always call destructors either.
-
@TheCPUWizard IMO if you have a finalizer that does anything other than throw an exception saying you're a big stupid-head for failing to
Disposethis object and suppress the finalizer, you're
.
-
@Gąska said in Resources want to be free!:
The buffer flush case is actually so vital that it probably has it's own special mechanism inside the runtime so that flushes happen even on exits associated with (controlled) crashing.
Nope. Unless you run in some baby crib environment that makes .NET look like deadly adventure, there will always be some fatal error scenarios that will have to skip destructors/finalizers and terminate process without flushing all the buffers - unless the programmer themselves ensures this doesn't happen.
If I take an axe to the CPU, some things in buffers will not get flushed to disk even if you wrote the code in C++ or C#. I think this doesn't bother me very much.
-
@dkf no need for an axe - just throw an exception in a destructor. Or just call
abort(). Among others.
-
I once supported an app where the Indians never closed sockets and it took them years to figure out that was a major bottleneck. Then they turned around and wrote their next app the same way and still don't know what's causing its bottlenecks.
-
@Zenith The OS will recover them. Eventually. The issue is that you want faster recovery than the default offered by the built-in backstop (for good reason).
Other resources aren't as nice as that. Shared memory segments are sometimes leaked entirely, until reboot (when the OS can finally deal with them). Connections to Oracle databases are also reputed to be leaked nastily if not closed properly, and the leak exhibits itself as database processes that won't go away.
-
@dkf said in Resources want to be free!:
Connections to Oracle databases are also reputed to be leaked nastily if not closed properly, and the leak exhibits itself as database processes that won't go away.
I once happened upon some code in production that created new database connections in a loop, and sent one query on that connection. And did not close the connection.
The loop ran over a list of IDs and created a parameterized query. But the query string was concatenated with a string from userland, as well as using a parameter for the id.
The database was Oracle.
I don't think there was a single line without some serious issue in the entire class.
-
@Gąska said in Resources want to be free!:
If you actually read my posts instead of listening to the abridged version narrated by your shoulder aliens
My summarization of people posts reflect precisely what people intended to say
-
@levicki said in Resources want to be free!:
@Gąska said in Resources want to be free!:
So classy of you to cut off the quote right before I explained why it doesn't matter for this particular discussion.
I cut it off because explanation is irrelevant -- people who are wrong always have an explanation for their failures even when they do admit they were wrong.
But do I? Show me ONE other instance from the last 3 months of me admitting an error then immediately providing excuse for why it doesn't matter. There are several ways in which your statement is wrong, but the most important is THE FALSE PREMISE THAT I DO THAT ON REGULAR BASIS. Are you sure you aren't confusing me with someone else?
It's wrong to dismiss something as irrelevant just because it fits a pattern of other irrelevant things. But at least it's understandable. What isn't understandable is dismissing something because it fits a pattern WHEN THE PATTERN DOESN'T EXIST.
An example:
Imaginary example in lieu of an actual quote of me doing something that you alleged I'm doing all the time! Yay!
@Gąska said in Resources want to be free!:
An average C++ developer does use additional libraries that wrap these for them, too.
You said "Standard C++ Library". Additional libraries are not "Standard C++ Library".
C++ standard library abstracts away manual management of all resources that C++ standard library uses. And there's a lot of them. Of course it doesn't abstract away resources it doesn't know about. I don't understand why you're acting so smug for noticing that. Or what change it makes whether the resource in question is a mutex lock or a brush handle.
@Gąska said in Resources want to be free!:
Well, your posts are full of factually incorrect statements.
Citation needed.
How about the part that more or less started this entire argument:
"You implied by your joke that Raymond Chen is incompetent programmer and then you made it worse by suggesting an average C# developer might know better."
Literally everything you said in that sentence is false.
Plus a whole bunch of non-sequiturs - not necessarily incorrect things themselves, but not the least bit relevant to anything I've ever said prior to it. Your quip about many ways to allocate memory in C++ especially made me chuckle.
-
@dkf said in Resources want to be free!:
Connections to Oracle databases are also reputed to be leaked nastily if not closed properly, and the leak exhibits itself as database processes that won't go away.
Which you will discover when Oracle charges you license fees for each instance of those processes.
-
-
@HardwareGeek said in Resources want to be free!:
@dkf said in Resources want to be free!:
Connections to Oracle databases are also reputed to be leaked nastily if not closed properly, and the leak exhibits itself as database processes that won't go away.
Which you will discover when Oracle charges you license fees for each instance of those processes.
Filed under: Exception ORA-$$$
-
@levicki said in Resources want to be free!:
I would appreciate if people would only downvote things which are factually incorrect, not just those they don't agree with and vice versa.
And we're the delusional ones?
-
@dkf said in Resources want to be free!:
Connections to Oracle databases are also reputed to be leaked nastily if not closed properly, and the leak exhibits itself as database processes that won't go away.
I haven't really noticed this, except in the case where I've written a query that is either inherently shitty or the DB shits itself and does something retarded and so the query ends up taking a long long long long time and then the connection goes away once the query finishes.
But I'd believe that this used to happen in older versions (I've been a heavy Oracle user since version 10 whatever letter).
