Enlightened
-
Just shared this thread with someone, who had this nugget of wisdom:
<endrift> Ah EFL, aka the port that always broke when making a change in WebKit, and no one ever cared <endrift> Haha case in point, the latest commit to WebKit: <endrift> colloquy://WKR https://trac.webkit.org/r185148 by Gyuyoung Kim (gyuyoung) [EFL][GTK] Fix build error since r185137 https://webkit.org/b/145596 Unreviewed, fix build break on EFL and GTK port.
-
-
you are so full of bullshit it's not funny. it had nothing to do with that, but you'd say anything to make your rant look good.
One of Us! One of Us!
-
He would be if not banned...?
-
<!-- 2af17a50-5e88-4353-901a-68f3051628f7 -->
-
Careful, that might get you a whoosh badge.
Not that I'm bitter or anything
-
Not banned by us.
-
Not sure if whoosh?
-
TDWTF didn't ban him. Allegedly, TDWTF is blocked on his corporate network. Nevertheless, he and @NeighborhoodButcher deserve their badges.
-
I don't know if you noticed, but there's apparently a sister topic at http://www.osnews.com/story/28553/Enlightened with our dear Carsten trying to justify himself again.
-
Who's "somebody_close" on OSNews? They deserve a call-out for their great replies.
-
I'm not quite sure I agree with what he says about
constthings (real threaded memory safety conditions are a bit more complicated than he seems to think) but he's still fighting the good fight well.
-
I didn't say we banned him. Merely he would be one of us if he weren't banned ;)
-
Ah. And since he isn't banned, he's One of Us!
-
Not sure about C, but in C++ the language in the standard makes const essentially the same as "thread safe" (for reading, not for writing). I imagine he was talking about that since he mentions "const functions", which don't exist, but what he says is true for const methods.
So you can read const objects from multiple threads without issue, and you can call const methods on an object from multiple threads without issue (in theory, there's a slight issue with mutable members, which should be locked, I don't recall how that is addressed)
-
Const implies parallel read safety. If you call const methods in separate threads, you should assume no data race. Of course that doesn't imply no synchronization underneath. There can be a ton of things going inside such method, but the caller should not care. It's the class responsibility to ensure thread safety. Const objects have much stronger guarantee, since they are visibly constant hence no data race should ever occur. Unless we talk references and pointers, but that's another story.
-
Carsten in the osnews responses:
people have made t-shirts with that message on it.
huh, two years ago: http://www.keepcalm-o-matic.co.uk/p/naughty-programmer-spank-spank-spank-now-go-fix-your-code-tut-tut-tut/
-
Nobody has voted for this poster yet. Why don't you?
Why doesn't this suprprise me?
-
But it's the 737th most popular! Maybe there are only 736 designs that have sold anything?
-
Const implies parallel read safety.
On a “variable”, yes. On a function (methods are syntactic sugar over functions in a general sense) then there's a rather larger diversity of what constitutes thread safety. Mere
constis insufficient to allow proper understanding of the safety features of an API. I'm writing an optimising compiler in my spare time at the moment, so these things matter a lot to me.
-
-
-
-
6502 assembly.
Which presumably Doesn't need an optimising compiler, maybe an assembler..
-
methods are syntactic sugar over functions in a general sense
Aren't they different names for pretty much the same thing?
-
Yep!
Well, methods are normally attached to objects; functions don't have to be.
-
What about subroutines?
-
In VB at least, they're functions that don't return a value
-
Too long since I've done any extensive coding in a language that's not objects all the way down. I'm sure I did know that when I was using c++
-
ew.
-
Really, it's no different to void-returning functions in JS and the like
-
ew at nomenclature.
-
In VB at least, they're functions that don't return a value
That's functionally equivalent to returning a type that only has one member value, and so which contains no information in that value. Everything else is just syntactic differences. (The unitary type is often called
unitas is its singleton value, but that's not really standard since any unitary type would work the same.)
-
Aren't they different names for pretty much the same thing?
Generally methods are attached to objects while functions are stand-alone. But ... yes.
-
Tsk tsk. In VB, functions and subroutines are both procedures, the former of which can be set to a value.
-
Const is enough to assume read thread safety, since no visible state should be modified. How this safety is internally implemented is unimportant for the caller. It's pretty much the same logic as with const variables - you won't have a race when nothing visible to the caller gets modified. Since we're designing against interfaces, that's all the info we need. If you get a race when calling a const method in parallel, somebody did a lousy job.
-
Yes, but there are tighter guarantees possible as well (such as stating that the result depends only on the values of the arguments passed in, which is extremely useful for optimisation purposes) and const isn't enough to cover that. There are a few other places where C++'s semantics slightly miss what is useful too, such as being able to tell the compiler that it can safely assume the result of a function won't alias anything else in the caller, i.e., the function is working like an allocator.
I expect that this stuff will inform future directions of C++ optimisation hints.
-
What about subroutines?
GOTO labels with callsite being put on a stack.
Filed under: get off my lawn
-
I expect that this stuff will inform future directions of C++ optimisation hints.
Quite a few of which various compilers already implement (
__attribute__((pure/const)),__attribute__((malloc))etc).But I'm not sure I agree with
constindicating thread safety for reading (not without a few additional assumptions).constprevents you from modifying the object, but it doesn't guarantee that nobody else is changing it concurrently (so assumption #1 would be that the object isconstin all concurrent contexts). Next, nothing is preventing aconstmethod from having side effects (i.e., changing state external to the object), and that may have a race condition. (Then there'smutablefor instance. And finally, this being a C-based language, you can always try to get clever in other ways.)So,
constmay indicate thread safety (for reading) in a sane code base (*), but there's no part of the language that enforces that (AFAIK).constexprgets closer...Edit: (*) maybe. you still need to know that nobody else is accessing the same object in a non-const way.
-
Yes, but there are tighter guarantees possible as well (such as stating that the result depends only on the values of the arguments passed in, which is extremely useful for optimisation purposes) and const isn't enough to cover that. There are a few other places where C++'s semantics slightly miss what is useful too, such as being able to tell the compiler that it can safely assume the result of a function won't alias anything else in the caller, i.e., the function is working like an allocator.
There indeed could be more hints introduced for compilers to do their job better. But, as far as const methods go, you are safe to assume that calling such method in parallel is fine. There a very good presentation by Herb Sutter about this: http://channel9.msdn.com/posts/C-and-Beyond-2012-Herb-Sutter-You-dont-know-blank-and-blankBut I'm not sure I agree with const indicating thread safety for reading (not without a few additional assumptions). const prevents you from modifying the object, but it doesn't guarantee that nobody else is changing it concurrently
You cannot (should not) modify visible state via const methods, therefore there is no possibility that anything you observe will change. You assume modifying such state, but it shouldn't be done with const methods, therefore the argument for const remains valid. (Unless someone makes crap code which breaks this contract.)
Next, nothing is preventing a const method from having side effects (i.e., changing state external to the object), and that may have a race condition. (Then there's mutable for instance. And finally, this being a C-based language, you can always try to get clever in other ways.)
No, there is nothing preventing being stupid, but we assume we're dealing with programmer who doesn't want to fight against the Standard and the compiler (and common sense). Note: never confuse visible state with internal state. Const methods should not modify visible state, but can freely modify internal state and should do it in a synchronized way. The same goes with external resources - since they are not a part of the state of given object, such resources also should be synchronized. Again - const doesn't mean no synchronization; const means no visible state will be modified, so you can concurrently read is as you wish.
So, const may indicate thread safety (for reading) in a sane code base (*), but there's no part of the language that enforces that (AFAIK). constexpr gets closer...
Actually the language does enforce that by the means of making "this" const, and the programmer must explicitly bypass that by using mutable. Therefore it is an explicit intention of the programmer to potentially make it not thread-safe. As for constexpr - it doesn't get closer, since in the context of runtime, it means the same as const.
-
There indeed could be more hints introduced for compilers to do their job better.
The ones that make a big difference are the ones that let the compiler hoist things out of loops or reorder function calls. Those are a real big deal…
-
The compiler is free to do any reordering as long as the "as-if" rule stands. As far as I know, modern compilers, like clang, can perform really crazy optimizations.
-
As far as I know, modern compilers, like clang, can perform really crazy optimizations.
I'm quite aware of what clang (or rather LLVM, which is clang without the C and C++ language parser parts) can do, as I'm using it for my own things. It's pretty awesome, and I've used it to accelerate code by over 20 times (yes, my jaw hit the floor when I got those figures).
-
NeighborhoodButcher, you saved me. I was a huge Tizen fan until a min. (or a lot of them) ago. Now I never want to touch it. I hope the architect earns a Darwin, but to be nice I hope he doesn't feel pain when doing such.
I also hope he eventually goes to college and learns to program.
And for the love of Buddhism, which is about being humble and removing desires, while following other Enlightened advice by "doing practical things while practicality still applies", fucking listens to just one person once in his life.
I will be supporting Ubuntu instead. And maybe retrain in TKD so I can go to Korea and beat the shit out of him in a legal challenge/official gym/match, then forgive myself and resume my own study of same humbleness and such. But I'm not there yet, so
-
Many years (decades) ago, when I was working on optimizing compilers, there was a challenge circulating.... Develop a tic-tac-toe game, the computer was to play both sides. Each side was to take the "upper left" best square. As a result the game was deterministic (the outcome would always be the same....The output was to be the state of the board after each "player"s turn...
The actual challenge was to develop a compiler that would take "C" source and optimize it to the point of being a single printf...
-
I'm not quite sure I agree with what he says about const things (real threaded memory safety conditions are a bit more complicated than he seems to think) but he's still fighting the good fight well.
To be honest I don't understand why he even talks about memory safety. GUI widgets are generally not thread-safe and I don't think Enlightenment is an exception. It would be a lot of work, because the underlying API is not in either X or Win32.
Const is not about memory safety anyway. It is about contract. Function receiving a const pointer (or reference) promises not to modify the pointee via that pointer and function returning const pointer requests the pointee not to be modified via that pointer. This is the semantics enforced, sans cast, by the language and it allows handing out pointers to parts of internal state to avoid copying while keeping control over invariants.
It does not mean the pointee can't be modified via different pointer, which is why it is useless for optimization, but for encapsulation it is good enough, because author of the object has control over where they pass non-const pointers.
In most contexts taking const pointer also means that the function does assume anything about lifetime of the pointee and won't keep the pointer beyond it's return. This is not enforced by the language, but it is common expectation. It is this that Enlightenment violates.
Not sure about C, but in C++ the language in the standard makes const essentially the same as "thread safe" (for reading, not for writing).
There is a big problem with the phrase “thread safe”. It can mean a lot of things.
constonly guarantees (or should, there is stillconst_cast) that there won't be data race in object x between two functions that take x by const pointer/reference (const member function takes invocant by const reference) and don't also have access to non-const pointer/reference.
-
It would be a lot of work, because the underlying API is not in either X or Win32.
The real underlying API with X11 is thread-safe (it's a network protocol with everything explicitly identified) but hardly anyone works at that level because it's annoyingly verbose and fussy. The simplest way of making Xlib thread-safe in practice is to give each thread its own
Displayso that they don't share anything (except via the Xserver as independent clients) but for some reason that seems to be an unpopular approach; people keep wanting to have multiple threads scribbling on the same little bit of window surface (and that's what is problematic…)
-
he simplest way of making Xlib thread-safe in practice is to give each thread its own
DisplayThat makes it reentrant, but not thread safe, because you still have to access each object (window, pixmap, etc.) from only one thread consistently.
-
That makes it reentrant, but not thread safe, because you still have to access each object (window, pixmap, etc.) from only one thread consistently.
You're getting mixed up between the local proxy objects and the underlying server-side real objects. The proxy instances are not thread-safe, but the underlying objects are (quite possibly by serialization, but that's the implementation strategy) because X11 was always designed to support multiple processes (on multiple hosts).
-
I am forgetting that X does not have any object ownership. Any process can fuck with any window.
However when programming in Xlib (and not Xcb), you are working with the proxy objects, so those matter.
And GDI does have object ownership and a window can only be manipulated by the thread that created it, so as portable library Enlightenment can't offer anything more anyway.
