- recovering from std::bad_alloc in std::string reserve - 8 Updates
- Niuce C++14-feature - 17 Updates
| Bonita Montero <Bonita.Montero@gmail.com>: May 25 12:56PM +0200 You've got a 2GB address-space and not a contignous piece of memory which fits to your 900MB. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 25 01:00PM +0200 > return an error code or print an informative error message or something > that indicates what happened, rather than silently failing and doing > nothing? On the other side: if bad_alloc is the only expectable exception you could stick with "..." |
| scott@slp53.sl.home (Scott Lurndal): May 25 02:55PM >You've got a 2GB address-space and not a contignous piece of >memory which fits to your 900MB. It doesn't need to be contiguous. But it needs to exist either as real memory or as configured backing store (i.e. swap space). |
| Paavo Helde <myfirstname@osa.pri.ee>: May 25 06:42PM +0300 25.05.2021 17:55 Scott Lurndal kirjutas: >> memory which fits to your 900MB. > It doesn't need to be contiguous. But it needs to exist either > as real memory or as configured backing store (i.e. swap space). For fitting a 900 MB std::string into a memory one needs 900 MB of contiguous address space and Bonita is right in pointing out this might be problematic because of memory fragmentation. The OP has 16 GB of RAM so there is plenty of physical memory, it's just a problem with the limited address space in 32-bit programs. |
| MrSpook_Ann1u@d0v_5eh1bqgd.com: May 25 04:10PM On Tue, 25 May 2021 18:42:54 +0300 >> as real memory or as configured backing store (i.e. swap space). >For fitting a 900 MB std::string into a memory one needs 900 MB of >contiguous address space and Bonita is right in pointing out this might Why? Only the virtual memory address space needs to be contiguous, the real memory pages storing the string could be all over the place. |
| Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr>: May 25 04:21PM > be problematic because of memory fragmentation. > The OP has 16 GB of RAM so there is plenty of physical memory, it's just > a problem with the limited address space in 32-bit programs. Win7 32bit cannot access 16G. Limit is 3.5G. She needs 64bit Windows to use it. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 25 06:23PM +0200 > Why? Only the virtual memory address space needs to be contiguous, > the real memory pages storing the string could be all over the place. OMG, what a stupid statement. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 25 06:23PM +0200 > It doesn't need to be contiguous. ... I don't know exactly since when, but the standard-containers guarantee linear memory for years. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 25 12:02AM -0700 On 5/25/2021 12:00 AM, Bonita Montero wrote: > Lock-free algorithms never wait inside the kernel. > Otherwise they woudln't be lock-free. Oh argh! Did you read where I mentioned predicates? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 25 12:03AM -0700 On 5/24/2021 11:59 PM, Bonita Montero wrote: >> You are the one who made Kaz correct you. I corrected you as well. > But you are wrong about which topic. > Sorry, but that's very weak, losing your memories so shortly. No, I just have to end up teaching you again. Oh well. The new thread will be beneficial to you and, perhaps, others. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 25 12:04AM -0700 On 5/25/2021 12:01 AM, Bonita Montero wrote: > Whatever you're thinking about - empoying kernel-facilities > along with a lock-free stack makes the stack non lock-free. > Lock-free algorithms never wait inside the kernel ! Yawn.... Have you ever heard of a fast path? If there is work to be done, it will be lock-free. If its time to wait, it will wait. Yawn. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 25 09:04AM +0200 > No, I just have to end up teaching you again. Oh well. > The new thread will be beneficial to you and, perhaps, others. The discussion was about whether mutexes could be realized only with as counting mutexes and not whether they could be realized with compare-and-swap only. You have a weak memory ! |
| Bonita Montero <Bonita.Montero@gmail.com>: May 25 09:05AM +0200 >> Lock-free algorithms never wait inside the kernel. >> Otherwise they woudln't be lock-free. > Oh argh! Did you read where I mentioned predicates? Yes, this predicates are polled with all lock-free algorithms. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 25 09:07AM +0200 > Yawn.... Have you ever heard of a fast path? ... There is no fast- or slow path distiction with lock-free algorithms. There couldn't be a slow path inside the kernel because "lock-free" algorithms woudln't be lock-free if they wait inside the kernel. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 25 12:07AM -0700 On 5/25/2021 12:05 AM, Bonita Montero wrote: >>> Otherwise they woudln't be lock-free. >> Oh argh! Did you read where I mentioned predicates? > Yes, this predicates are polled with all lock-free algorithms. The predicate is polled in a condvar as well, yawn. Getting tired. Just try to think about it some more. I will get back to you tomorrow. I have some other work to do. Will but out Relacy. Its fun to use. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 25 12:08AM -0700 On 5/25/2021 12:07 AM, Chris M. Thomasson wrote: > The predicate is polled in a condvar as well, yawn. Getting tired. Just > try to think about it some more. I will get back to you tomorrow. I have > some other work to do. Will but out Relacy. Its fun to use. Bust out Relacy! Damn Typos! |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 25 12:09AM -0700 On 5/25/2021 12:04 AM, Bonita Montero wrote: > The discussion was about whether mutexes could be realized only > with as counting mutexes and not whether they could be realized > with compare-and-swap only. You have a weak memory ! You said they must use a semaphore, or CAS or something. Nope, you are wrong. And we, Kaz and I had to correct you. I remember it. Anyway, I have to take a look at some other code right now. Will get back to you in a new thread sometime tomorrow, deal? Okay. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 25 09:10AM +0200 > The predicate is polled in a condvar as well, yawn. ... A condvar isn't a lock-free structure. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 25 12:10AM -0700 On 5/25/2021 12:07 AM, Bonita Montero wrote: >> Yawn.... Have you ever heard of a fast path? ... > There is no fast- or slow path distiction with lock-free algorithms. Yeah, sure. Whatever you say. Yawn. lol. Yawn. Rolling eyes. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 25 09:11AM +0200 > You said they must use a semaphore, or CAS or something. ... I said you must be counting, but you gave a good example to do it without counting. But nevertheless a semaphore or more correctly a binary semaphore is necessary for the slow path. |
| MrSpook_cjz9@ngfllgqd.edu: May 25 09:02AM On Mon, 24 May 2021 18:14:26 +0200 >If you don't need synchronization you won't need it for fork()ing >#and threading as well. Then you simply could fire a thread with >thread( func, params ... ).detach() and forget the thread. What a pity I can't find some ascii art of someone with their head in their hands. You just Don't Get It despite myself and at least 2 other people trying to explain to you the advantages of multi process in certain situations. Whatever, carry on in clueless ignorance, I can't be bothered arguing anymore. |
| MrSpook_43zpj5@zrdy.biz: May 25 09:02AM On Mon, 24 May 2021 18:15:31 +0200 >> English comprehension problem? >I've shown that fork()ing is much more slower than to create a thread. >And even more a lot slower when pages are CoWd. For the use cases of fork the time of creation is irrelevant. |
| MrSpook_m0gtwlu6_g@j_cyo9l9.edu: May 25 09:05AM On Mon, 24 May 2021 18:51:58 +0200 >means that plugins, extensions, tabs, etc., can crash without bringing >down the whole browser. It costs - especially in ram - but you get >benefits from it. Yup. Also some browsers - eg firefox - started out using seperate processes for seperate tabs but switched over to multithreading - presumably to make porting to Windows easier - with the consequent drop in reliability. Now some have gone back to multi process which also has the benefit of making some kind of javascript hacks difficult if not impossible if each tab is a seperate process. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 25 12:53PM +0200 >> I've shown that fork()ing is much more slower than to create a thread. >> And even more a lot slower when pages are CoWd. > For the use cases of fork the time of creation is irrelevant. F.e. if you have a webserver that fork()s for every request, that's relevant as in most other cases. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 25 12:54PM +0200 >> thread( func, params ... ).detach() and forget the thread. > What a pity I can't find some ascii art of someone with their head in their > hands. The above is a trivial statement. And you won't have to have any shared memory, you simply pass the parameters to the thread and they're destructed when the thread ends. That's magnitudes more convenient than fork() ing and having shared memory. |
| 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