- Where are the exception-objects allocated? - 19 Updates
- std::atomic<T>::is_lock_free() - 5 Updates
- Where are the exception-objects allocated? - 1 Update
| Sam <sam@email-scan.com>: Nov 15 06:34AM -0500 Bonita Montero writes: >>> "unspecified storage" isn't a precise answer. >> It is precise answer to question asked. ... > "unspecified" isn't precise. It is precise enough for every C++ developer. Next thing you know, you'll be demanding to know exactly what "undefined behavior" is, in a given situation, right? |
| Sam <sam@email-scan.com>: Nov 15 06:36AM -0500 Bonita Montero writes: >> implementation allocates the storage that they are stored in. ... > I know that this is unspecified. > But I'm interested how this is actually implemented. Feel free to download the source code to gcc and libstdc++, and see for yourself. If you are so desperate to find out, that would be the only way how; excepting the very unlikely possibility that whoever wrote that is around here. Otherwise: nobody else knows, or cares. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 15 01:33PM +0100 >> "unspecified" isn't precise. > It is precise enough for every C++ developer. As I said I didn't ask to develop according to that but just for curiosity. And in this sense the answer isn't precise. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 15 01:35PM +0100 > That IS a thing every ordinary developer has to know, James. > My only Idea is a handler, so that another part of the program can free(), > but that would guarantee nothing. Or to loop and wait as it did. I don't believe that they actually do a infinite malloc()-loop. As I said LLVM's libc++ uses a special function like malloc and if it fails std::terminate() is simply called. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 15 01:37PM +0100 > Feel free to download the source code to gcc and libstdc++, and see for > yourself. Read the complete thread before you post! I already found this (https://libcxxabi.llvm.org/spec.html): | void* __cxa_allocate_exception(size_t thrown_size) throw(); | Effects: Allocates memory to hold the exception to be thrown. | thrown_size is the size of the exception object. Can allocate | additional memory to hold private data. If memory can not be | allocated, call std::terminate(). | Returns: A pointer to the memory allocated for the exception object. This looks to me the usual and pragmatical way it is done. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Nov 15 10:00AM -0500 On 11/15/19 6:34 AM, Sam wrote: >>> It is precise answer to question asked. ... >> "unspecified" isn't precise. > It is precise enough for every C++ developer. Agreed. Implementation-defined behavior is "unspecified behavior where each implementation documents how the choice is made" (3.4.1). The committee specifies that something is implementation-defined whenever it believes that there can be a good reason why the developer might need to know which choice an implementation has made. It follows that if the behavior is unspecified, and NOT implementation-defined, the committee believes that developers will generally not need to know which choice was made. That's relevant here, because the way memory is allocated for exception objects is a prime example of that second category. Since most developers don't need to know, most developers don't know. Just a few experts who know a lot more about how a given implementation works than most people, will have the answers to Bonita's question, and most of those people are much easier to find in a forum specific to the implementation that they're experts on, than they would be in this newsgroup. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 15 04:19PM +0100 > The committee specifies that something is implementation-defined > whenever it believes that there can be a good reason why the developer > might need to know which choice an implementation has made. Ar there only idiots discussing here? It doesn't matter if the standard doesn't say how the exception-objects might be allocated. It is never- theless an interesting question. If I had asked how exceptions are implemented with zero overhead when not thrown I'd got a lot of answers without the stupid objection, that the standard doesn't make any statements about this. Some folks here just can't bear that there's a question the can't answer which frustrades them that the say that this question doesn't matter. > those people are much easier to find in a forum specific to the > implementation that they're experts on, than they would be in this > newsgroup. I didn't find a forum. And even the same question on Stack Overlfow, (which reaches a lot more developers) from someone else some time ago yielded no satisfying annswer. So no one seems to be concerned about that. But I think every impementation handels this issue like clang / libc++ and does a dynamic allocation, thereby assuming that the small allo- cation an exception-object usually needs is very unlikely to fail. |
| Sam <sam@email-scan.com>: Nov 15 11:12AM -0500 Bonita Montero writes: >> whenever it believes that there can be a good reason why the developer >> might need to know which choice an implementation has made. > Ar there only idiots discussing here? No, but you're doing your best to tip the scales. > It doesn't matter if the standard > doesn't say how the exception-objects might be allocated. It is never- > theless an interesting question. Here's your merit badge for asking interesting questions. Wear it proudly, you earned it. Congratulations. > (which reaches a lot more developers) from someone else some time ago > yielded no satisfying annswer. So no one seems to be concerned about > that. Right. To any rational person, that would've been a big honking clue. What about you? |
| Sam <sam@email-scan.com>: Nov 15 11:14AM -0500 Bonita Montero writes: >> Feel free to download the source code to gcc and libstdc++, and see for >> yourself. > Read the complete thread before you post! Unfortunately, I did. > | allocated, call std::terminate(). > | Returns: A pointer to the memory allocated for the exception object. > This looks to me the usual and pragmatical way it is done. Excellent. Now, aren't you curious how this "__cxa_allocate_exception" does about its business? And after you figure that out, I'm sure you'll be curious enough to know the precise semantics down to the transistor level. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 15 05:16PM +0100 >> Ar there only idiots discussing here? > No, but you're doing your best to tip the scales. No, I'm not. It's the folks here that seems to be frustrated about questions they can't answer. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 15 05:17PM +0100 >>> for yourself. >> Read the complete thread before you post! > Unfortunately, I did. If you did the above answer would be senseless. > does about its business? And after you figure that out, I'm sure you'll > be curious enough to know the precise semantics down to the transistor > level. It's a normal heap-allocation. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Nov 15 08:45AM -0800 On Friday, November 15, 2019 at 10:19:29 AM UTC-5, Bonita Montero wrote: > Ar there only idiots discussing here? It doesn't matter if the standard > doesn't say how the exception-objects might be allocated. It is never- > theless an interesting question. I'm not denying that it might be an interesting question for some people (I'm not particularly interested in it, myselft) - I'm merely explaining why there are better places to go to get good answers to your question. If you don't care whether the answers you get are good, or for that matter, whether you get any answers at all, this is no worse a place to post them than any other. > If I had asked how exceptions are implemented with zero overhead when > not thrown I'd got a lot of answers without the stupid objection, that > the standard doesn't make any statements about this. That's because the question of whether or not they can be (and have been) implemented with zero overhead has a great deal of bearing upon whether or not it's a good idea to use them in any particular circumstance. The zero-overhead approach has the consequence that exceptions, when used, are generally very slow. I've seen code that threw and caught an exception within the same function, as a glorified goto - and the fact that they are very slow is an important reason for not doing that. > Some folks here just can't bear that there's a question the can't > answer which frustrades them that the say that this question doesn't > matter. It doesn't frustrate me that I can't answer it - the answer has no importance for anything I've ever done or could ever imagine doing (I don't imagine myself working as a developer for a C++ compiler, which is the only context in which I would be interested in the answer). If it had ever been important to me, I would have found out. > > implementation that they're experts on, than they would be in this > > newsgroup. > I didn't find a forum. Virtually every major compiler has some kind of forum; gcc and microsoft have dozens, if not hundreds of them - the hard part is choosing the right one (and it IS a hard task). But the best place to find the right gcc forum is to ask in a gcc forum, and similarly for Microsoft. Keep in mind that usenet is not the only place to go to for discussion forums - mailing lists and chat rooms are among the most common alternatives. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Nov 15 08:47AM -0800 On Friday, November 15, 2019 at 11:16:29 AM UTC-5, Bonita Montero wrote: > > No, but you're doing your best to tip the scales. > No, I'm not. It's the folks here that seems to be frustrated about > questions they can't answer. That suggests that your ability to guess at people's unstated motivations is not very reliable. I recommend not relying on it for anything important. |
| Sam <sam@email-scan.com>: Nov 15 11:51AM -0500 Bonita Montero writes: >>> Read the complete thread before you post! >> Unfortunately, I did. > If you did the above answer would be senseless. It's not my fault you lack the minimal capacity to understand its brilliance. >> about its business? And after you figure that out, I'm sure you'll be >> curious enough to know the precise semantics down to the transistor level. > It's a normal heap-allocation. Yes, but how does that work? I guess you don't know the answer to that, and that frustrates you. Too bad. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 15 06:45PM +0100 >> questions they can't answer. > That suggests that your ability to guess at people's unstated motivations > is not very reliable. It is reliable since this can be derived from the kind of answer. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 15 06:52PM +0100 > whether or not it's a good idea to use them in any particular > circumstance. The zero-overhead approach has the consequence that > exceptions, when used, are generally very slow. Not true. Exception-handling with concatenated with al TLS-pointer to the top stack-frame is also slow. > I've seen code that threw and caught an exception within the same > function, as a glorified goto - and the fact that they are very > slow is an important reason for not doing that. That might get optimized away by the compiler. > It doesn't frustrate me ... Obviously not you, but others in this thread. > It doesn't frustrate me that I can't answer it - the answer has no > importance for anything I've ever done or could ever imagine doing Knowing how zero-overhead exception-handling is implemented also doesn't matter for practical programming. It's just sufficient to know that not throwing costs nothing, throwing costs a lot and there might be a lot of unwinding-code. Nevertheless it's interesting to know how it works. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 15 06:56PM +0100 >> If you did the above answer would be senseless. > It's not my fault you lack the minimal capacity to understand its > brilliance. Another time: if you had read that I quoted a part of the LLVM-website your posting would be gratuitous. >> It's a normal heap-allocation. > Yes, but how does that work? I guess you don't know the answer to that, > and that frustrates you. Too bad. Doesn't matter. I asked just to know if the throwing might fail because the exception-object couldn't be created. There are several heap-alloca- tion-strategies which are all equally appropriate for this purpose. Heap-allocation is a different topic. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 15 09:13PM On 14/11/2019 12:07, Bonita Montero wrote: > occur when you don't catch the exception by reference (I don't > see any reason to catch exception-objects by value anyway). So > there are good reasons to not to provide both. The exception object is allocated in unspecified storage the details of which are specific to a particular implementation and thus off topic here. /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 15 01:47PM -0800 On 11/13/2019 8:59 AM, Bonita Montero wrote: > Can anyone tell me what would be a proper way to allocate storage > for an exception-object being thrown without causing that this > allocation might fail? Sometimes, exceptions are banned for certain environments for good reasons. > And remember that these objects even have > to live longer than a thread because you might refer to it by > an std::exception_ptr. This is completely up to the implementation. They can store/do things however they want to, as long as it complies to the std. Damn, JG, how many exceptions would have to be nested to exhaust memory in a thread such that throw has nothing left? You know the answer right? I remember doing an excepting thing in C basically abusing setjmp/longjump. It used TLS. Better to ask in a compiler group. For instance, I found some odd things going on in pellesc. Asked over there, and received extremely informative answers. Well, they said they might get fixed in the next release. Okay, good enough. :^) |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 15 09:31AM +0100 >> data has an undefined behaviour. And there's not the least necessitiy >> in using unaligned atomics. > You are JG, right? Tell me of the sense to use non-aligned atomics. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 15 09:32AM +0100 >> Lock-free Atomic operations don't depend on the operating-system, ^^^^^^^^^^^^^^^^ > Are you sure about that? Remember that one can implement a pure std > c++11 atomic lib using semaphores. ... Wat of the underlined wording above don't you unterstand? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 15 12:59PM -0800 On 11/15/2019 12:31 AM, Bonita Montero wrote: >>> in using unaligned atomics. >> You are JG, right? > Tell me of the sense to use non-aligned atomics. Not sure what that even means. Are you talking about L2 cache alignment and proper padding? Its used to avoid false sharing. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 15 01:06PM -0800 On 11/15/2019 12:32 AM, Bonita Montero wrote: >> Are you sure about that? Remember that one can implement a pure std >> c++11 atomic lib using semaphores. ... > Wat of the underlined wording above don't you unterstand? Ideally lock-free atomic operations should boil down to pure hardware instructions. Take a 32 bit x86. The atomic operation of a double word should be using CMPXCHG8B. However, we cannot know what some operating system is doing. Like I said, the simple lock-free stack on Windows uses some funky OS support. |
| scott@slp53.sl.home (Scott Lurndal): Nov 15 09:47PM >> Tell me of the sense to use non-aligned atomics. >Not sure what that even means. Are you talking about L2 cache alignment >and proper padding? Its used to avoid false sharing. Why do you bother with BM? It deliberatly removes attributes so it's impossible to see who said what to whom. In any case, unaligned atomics are useless, and many architectures won't support them (particularly in uncachable memory regions like those mapped to PCI express bars (and PCI express endpoints -may- support atomic operations...)). I suspect that most architectures avoid supporting unaligned atomics because they might split cache lines which would make it impossible (or very time consuming) to support atomic semantics for the access. |
| Udo Steinbach <trashcan@udoline.de>: Nov 15 12:16PM +0100 Am 2019-11-13 um 19:28 schrieb Bonita Montero: > But I'm interested how this is actually implemented. Some years ago I have tested this with g++. Normal malloc(), if this misses, special static memory area, if this misses, normal malloc() --- endless loop. Yes, your found __cxa_allocate_exception(). I am not sure, but I can't remember of calling a user defined handling of this situation. That IS a thing every ordinary developer has to know, James. My only Idea is a handler, so that another part of the program can free(), but that would guarantee nothing. Or to loop and wait as it did. -- Fahrradverkehr in Deutschland: http://radwege.udoline.de/ GPG: A245 F153 0636 6E34 E2F3 E1EB 817A B14D 3E7E 482E |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment