Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #9464 > unrolled thread
| Started by | Paul <pchristor@yahoo.co.uk> |
|---|---|
| First post | 2011-08-29 23:26 -0700 |
| Last post | 2011-08-30 16:45 -0700 |
| Articles | 20 on this page of 197 — 20 participants |
Back to article view | Back to comp.lang.c++
bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-29 23:26 -0700
Re: bad alloc Krice <paulkp@mbnet.fi> - 2011-08-30 02:14 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 06:26 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 14:34 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 06:54 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 15:02 +0100
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 15:06 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 07:20 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 15:31 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 07:47 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 15:52 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 08:00 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 16:15 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 10:31 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 18:58 +0100
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 19:18 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 16:17 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-31 00:56 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 17:11 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-31 01:24 +0100
Re: bad alloc Ian Collins <ian-news@hotmail.com> - 2011-08-31 12:33 +1200
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 18:38 -0700
Re: bad alloc Noah Roberts <roberts.noah@gmail.com> - 2011-08-30 20:07 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-31 04:04 -0700
Re: bad alloc Noah Roberts <roberts.noah@gmail.com> - 2011-08-31 09:17 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-31 14:59 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-01 00:50 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-09-01 12:41 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-01 05:00 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-09-01 13:59 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-01 06:35 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-09-01 14:50 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-01 13:51 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-09-01 21:58 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-01 14:05 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-09-01 22:08 +0100
Re: bad alloc Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-02 03:16 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-02 04:12 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-09-02 15:08 +0100
Re: bad alloc Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-02 03:07 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-02 04:15 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 11:21 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 10:46 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 18:58 +0100
Re: bad alloc "Waldek M." <wm@localhost.localdomain> - 2011-08-31 20:58 +0200
Re: bad alloc "io_x" <a@b.c.invalid> - 2011-09-03 10:13 +0200
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-05 18:53 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 16:28 -0700
Re: bad alloc Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-01 00:49 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-01 04:50 -0700
Re: bad alloc Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-02 03:17 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-02 04:21 -0700
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-01 16:23 -0700
Re: bad alloc Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-02 03:19 -0700
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-03 15:37 -0700
Re: bad alloc Dombo <dombo@disposable.invalid> - 2011-09-04 09:25 +0200
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-01 16:20 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-08-30 06:54 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 07:12 -0700
Re: bad alloc Dombo <dombo@disposable.invalid> - 2011-08-30 22:58 +0200
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 15:56 -0700
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-08-31 09:28 +0000
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-31 04:20 -0700
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-02 14:57 +0000
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-02 08:35 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-08-31 04:25 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-08-30 03:26 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 05:54 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 14:30 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 07:00 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-08-31 00:37 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-31 04:26 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-08-30 07:03 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 07:57 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 16:04 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 08:15 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 16:20 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 10:37 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 18:41 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 10:49 -0700
Re: bad alloc Asger-P <junk@asger-p.dk> - 2011-08-31 10:33 +0200
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-31 04:22 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-08-30 16:04 -0700
Re: bad alloc Noah Roberts <roberts.noah@gmail.com> - 2011-08-30 20:02 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-08-30 20:33 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-08-31 01:30 -0700
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-08-31 09:23 +0000
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-08-31 04:21 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-08-31 04:47 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-31 05:35 -0700
Re: bad alloc Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-01 01:08 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-01 03:56 -0700
Re: bad alloc Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-02 04:18 -0700
Re: bad alloc Dombo <dombo@disposable.invalid> - 2011-09-03 18:37 +0200
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-03 13:39 -0700
Re: bad alloc red floyd <no.spam.here@its.invalid> - 2011-09-03 13:45 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-03 13:51 -0700
Re: bad alloc Sjouke Burry <burryNULNULFOUR@PPLLAANNEETT.NNLL> - 2011-09-04 00:14 +0200
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-03 15:51 -0700
Re: bad alloc Ian Collins <ian-news@hotmail.com> - 2011-09-04 12:15 +1200
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-04 05:00 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-05 18:13 -0700
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-03 15:45 -0700
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-02 15:40 +0000
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-02 09:33 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-02 14:06 -0700
Re: bad alloc "io_x" <a@b.c.invalid> - 2011-09-03 10:12 +0200
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-08-31 04:21 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-08-31 01:22 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-08-31 05:18 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-08-31 06:36 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-08-31 09:33 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-01 00:20 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-01 04:25 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-09-01 12:51 +0100
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-01 06:04 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-01 06:26 -0700
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-01 16:58 -0700
Re: bad alloc Joshua Maurice <joshuamaurice@gmail.com> - 2011-09-01 17:25 -0700
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-03 16:02 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-05 18:20 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-05 19:13 -0700
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-06 15:39 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-06 17:26 -0700
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-06 15:35 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-06 17:28 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-01 21:01 -0700
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-03 16:14 -0700
Re: bad alloc "io_x" <a@b.c.invalid> - 2011-09-05 10:31 +0200
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-05 18:36 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-06 04:09 -0700
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-06 15:49 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-06 17:11 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-07 00:24 -0700
Re: bad alloc Joshua Maurice <joshuamaurice@gmail.com> - 2011-08-31 09:59 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-08-31 11:24 -0700
Re: bad alloc Joshua Maurice <joshuamaurice@gmail.com> - 2011-09-01 16:29 -0700
Re: bad alloc Joshua Maurice <joshuamaurice@gmail.com> - 2011-09-01 16:42 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-01 21:37 -0700
Re: bad alloc Ian Collins <ian-news@hotmail.com> - 2011-09-02 17:45 +1200
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-03 16:20 -0700
Re: bad alloc Ian Collins <ian-news@hotmail.com> - 2011-09-04 12:03 +1200
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-04 10:56 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-05 18:50 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-06 00:12 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-06 03:04 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-07 00:08 -0700
Re: bad alloc Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-07 02:33 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-07 04:28 -0700
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-06 13:43 +0000
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-06 07:37 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-07 00:11 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-07 04:29 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-07 05:38 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-07 18:17 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-08 00:45 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-06 06:58 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-06 09:21 -0700
Re: bad alloc "Fred Zwarts \(KVI\)" <F.Zwarts@KVI.nl> - 2011-09-07 09:10 +0200
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-07 04:18 -0700
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-07 10:34 +0000
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-07 04:00 -0700
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-08 12:11 +0000
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-08 06:27 -0700
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-06 15:52 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-06 17:16 -0700
Re: bad alloc Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-07 02:39 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-07 04:14 -0700
Re: bad alloc Ian Collins <ian-news@hotmail.com> - 2011-09-06 17:00 +1200
Re: bad alloc Miles Bader <miles@gnu.org> - 2011-09-06 14:51 +0900
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-06 15:55 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-05 18:44 -0700
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-07 10:20 +0000
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-07 03:40 -0700
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-13 17:06 +0000
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-13 12:09 -0700
Re: bad alloc "Paul" <pchristor@yahoo.co.uk> - 2011-09-14 00:18 +0100
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-14 15:11 +0000
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-14 11:17 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-15 04:17 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-15 06:50 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-15 07:31 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-15 07:59 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-16 00:19 -0700
Re: bad alloc Noah Roberts <roberts.noah@gmail.com> - 2011-09-17 10:13 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-18 10:07 -0700
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-16 15:41 +0000
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-16 11:26 -0700
Re: bad alloc Joshua Maurice <joshuamaurice@gmail.com> - 2011-09-16 15:38 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-17 04:25 -0700
Re: bad alloc Joshua Maurice <joshuamaurice@gmail.com> - 2011-09-01 23:17 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-02 04:03 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-02 04:37 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-09-02 15:15 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-02 07:35 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-08-30 16:06 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 16:45 -0700
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | James Kanze <james.kanze@gmail.com> |
|---|---|
| Date | 2011-09-03 16:20 -0700 |
| Message-ID | <64024153-4384-44d8-aec8-b097c44e848e@t5g2000yqj.googlegroups.com> |
| In reply to | #9645 |
On Sep 2, 6:45 am, Ian Collins <ian-n...@hotmail.com> wrote:
> On 09/ 2/11 04:37 PM, Adam Skutt wrote:
[...]
> I agree. On a descent hosted environment, memory exhaustion is usually
> down to either a system wide problem, or a programming error.
Or an overly complex client request.
> If you require an application to be "robust" then you can use
> an external entity to manage and if necessary, restart it.
> This is common practice for system processes.
That's the correct response to a programming error or a system
wide problem. For a request which is part of a DOS attack, it
seems to be playing into the attacker's hand, and for a simply
unreasonable client request, it does seem unnecessary to abort
all other client connections. What's wrong with just responding
with an "insufficient resources" error?
[...]
> Indeed, robustness goes beyond a single application.
That's why robust servers run on dedicated machines (where they
are the only "application").
--
James Kanze
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-09-04 12:03 +1200 |
| Message-ID | <9cfti9FsstU5@mid.individual.net> |
| In reply to | #9715 |
On 09/ 4/11 11:20 AM, James Kanze wrote: > On Sep 2, 6:45 am, Ian Collins<ian-n...@hotmail.com> wrote: >> On 09/ 2/11 04:37 PM, Adam Skutt wrote: > > [...] >> I agree. On a descent hosted environment, memory exhaustion is usually >> down to either a system wide problem, or a programming error. > > Or an overly complex client request. Not spotting those is a programming (or specification) error! >> If you require an application to be "robust" then you can use >> an external entity to manage and if necessary, restart it. >> This is common practice for system processes. > > That's the correct response to a programming error or a system > wide problem. For a request which is part of a DOS attack, it > seems to be playing into the attacker's hand, and for a simply > unreasonable client request, it does seem unnecessary to abort > all other client connections. What's wrong with just responding > with an "insufficient resources" error? No, it doesn't. Which is why it's not a good idea to allocate an arbitrarily large chunk of memory in response to an external request. Where overly complex requests are easily to discard, the more insidious DOS attacks are those that make many, apparently reasonable, requests. To protect against those, finer resource limits (such as a finite set on input buffers) than the size of the heap should be used. > [...] >> Indeed, robustness goes beyond a single application. > > That's why robust servers run on dedicated machines (where they > are the only "application"). Indeed. That's why I run mine in their own container, with dedicated system resources. Dedicated machines are so last century! -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | James Kanze <james.kanze@gmail.com> |
|---|---|
| Date | 2011-09-04 10:56 -0700 |
| Message-ID | <8c52f625-7360-43c4-aee3-13b9a4484971@h9g2000vbr.googlegroups.com> |
| In reply to | #9717 |
On Sep 4, 1:03 am, Ian Collins <ian-n...@hotmail.com> wrote: > On 09/ 4/11 11:20 AM, James Kanze wrote: > > On Sep 2, 6:45 am, Ian Collins<ian-n...@hotmail.com> wrote: > >> On 09/ 2/11 04:37 PM, Adam Skutt wrote: > > [...] > >> I agree. On a descent hosted environment, memory exhaustion is usually > >> down to either a system wide problem, or a programming error. > > Or an overly complex client request. > Not spotting those is a programming (or specification) error! And the way you spot them is by catching bad_alloc:-). Seriously, the problem is very much like that of a compiler. Nest parentheses too deep, and the compiler will run out of memory. There are two solutions: specify an artificial nesting limit, which you know you can handle (regardless of how many connections are active, etc.), or react when you run out of resources. There are valid arguments for both solutions, and I've used both, in different applications. -- James Kanze
[toc] | [prev] | [next] | [standalone]
| From | Adam Skutt <askutt@gmail.com> |
|---|---|
| Date | 2011-09-05 18:50 -0700 |
| Message-ID | <2ab097e7-57e7-4e01-9d05-5630fe255646@f41g2000yqh.googlegroups.com> |
| In reply to | #9738 |
On Sep 4, 1:56 pm, James Kanze <james.ka...@gmail.com> wrote: > On Sep 4, 1:03 am, Ian Collins <ian-n...@hotmail.com> wrote: > > > On 09/ 4/11 11:20 AM, James Kanze wrote: > > > On Sep 2, 6:45 am, Ian Collins<ian-n...@hotmail.com> wrote: > > >> On 09/ 2/11 04:37 PM, Adam Skutt wrote: > > > [...] > > >> I agree. On a descent hosted environment, memory exhaustion is usually > > >> down to either a system wide problem, or a programming error. > > > Or an overly complex client request. > > Not spotting those is a programming (or specification) error! > > And the way you spot them is by catching bad_alloc:-). > No, you set upfront bounds on allowable inputs. This is what other engineering disciplines do, so I'm not sure why computer programmers would do something different. Algorithms that permit bounded response to unbounded input are pretty rare in the grand scheme of things. Even when they exist, they may carry tradeoffs that make them undesirable or unsuitable (e.g., internal vs. external sort). > Seriously, the problem is very much like that of a compiler. > Nest parentheses too deep, and the compiler will run out of > memory. There are two solutions: specify an artificial nesting > limit, which you know you can handle (regardless of how many > connections are active, etc.), or react when you run out of > resources. There are valid arguments for both solutions, and > I've used both, in different applications. The problem is reacting in a way that isolates the failure. Most language and operating systems make that very difficult. Adam
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-09-06 00:12 -0700 |
| Message-ID | <106bc6d3-129c-4de7-9d0e-00468b37448a@w28g2000yqw.googlegroups.com> |
| In reply to | #9773 |
On Sep 6, 3:50 am, Adam Skutt <ask...@gmail.com> wrote: > On Sep 4, 1:56 pm, James Kanze <james.ka...@gmail.com> wrote: > > > On Sep 4, 1:03 am, Ian Collins <ian-n...@hotmail.com> wrote: > > > > On 09/ 4/11 11:20 AM, James Kanze wrote: > > > > On Sep 2, 6:45 am, Ian Collins<ian-n...@hotmail.com> wrote: > > > >> On 09/ 2/11 04:37 PM, Adam Skutt wrote: > > > > [...] > > > >> I agree. On a descent hosted environment, memory exhaustion is usually > > > >> down to either a system wide problem, or a programming error. > > > > Or an overly complex client request. > > > Not spotting those is a programming (or specification) error! > > > And the way you spot them is by catching bad_alloc:-). > > No, you set upfront bounds on allowable inputs. This is what other > engineering disciplines do, so I'm not sure why computer programmers > would do something different. Because code runs in a more volatile environment and tends to handle more complex (models of) systems. An obvious example: a program operates on a set of X-es in one part, and on a set of Y-s in another. Both are being "added" to operation as user goes along. Given system limits, code can operate in a range on A X-es and 0 Y-s, or 0 X-es and B Y-s, and any many-a-combination in between. Whichever way you decide on a limit on max count of X or Y, some use will suffer. Compound this with the empirical observation that, beside X and Y, there's U, V, W and many more, and there you have it. Add a sprinkle of a volatile environment, as well as differing environments, because one code base might run in all sorts of them... A simple answer to this is to (strive to ;-)) handle OOM gracefully. Goran.
[toc] | [prev] | [next] | [standalone]
| From | Adam Skutt <askutt@gmail.com> |
|---|---|
| Date | 2011-09-06 03:04 -0700 |
| Message-ID | <918bba7a-4261-447b-8ac0-a9c12e568201@r21g2000yqr.googlegroups.com> |
| In reply to | #9780 |
On Sep 6, 3:12 am, Goran <goran.pu...@gmail.com> wrote: > On Sep 6, 3:50 am, Adam Skutt <ask...@gmail.com> wrote: > > > > > > > > > > > On Sep 4, 1:56 pm, James Kanze <james.ka...@gmail.com> wrote: > > > > On Sep 4, 1:03 am, Ian Collins <ian-n...@hotmail.com> wrote: > > > > > On 09/ 4/11 11:20 AM, James Kanze wrote: > > > > > On Sep 2, 6:45 am, Ian Collins<ian-n...@hotmail.com> wrote: > > > > >> On 09/ 2/11 04:37 PM, Adam Skutt wrote: > > > > > [...] > > > > >> I agree. On a descent hosted environment, memory exhaustion is usually > > > > >> down to either a system wide problem, or a programming error. > > > > > Or an overly complex client request. > > > > Not spotting those is a programming (or specification) error! > > > > And the way you spot them is by catching bad_alloc:-). > > > No, you set upfront bounds on allowable inputs. This is what other > > engineering disciplines do, so I'm not sure why computer programmers > > would do something different. > > Because code runs in a more volatile environment It does nothing of the sort! Code does not have to deal the physical environment: it doesn't have to be concerned with the external temperature, humidity, shock, weather conditions, etc. It does not care whether the computer has been placed in a server room or outside in the middle of the desert. Hardware frequently has to care about all of these factors, and many more. Operating systems provide reasonable levels of isolation between components: software can generally ignore the other software running on the same computer. Hardware design has to frequently care about these factors: the mere placement of ICs on a board can cause them to interfere with one another! The list goes on and on, and applies to all of the other engineering disciplines too. This is easily by far both the most absurd and most ignorant thing you've said yet, by a mile. > and tends to handle > more complex (models of) systems. > Because it's cheaper and easier to do such things in software, in no small part because many of the classical design considerations for hardware simply disappear. However, that doesn't change my statement on setting bounds in the least. > An obvious example: a program operates on a set of X-es in one part, > and on a set of Y-s in another. Both are being "added" to operation as > user goes along. Given system limits, code can operate in a range on A > X-es and 0 Y-s, or 0 X-es and B Y-s, and any many-a-combination in > between. Whichever way you decide on a limit on max count of X or Y, > some use will suffer. I'm not sure how you think this is irrelevant to this portion of the discussion, but it's not even true. The limit for both may be excessively generous for any reasonable use case. Moreover, plenty of hardware has to process two distinct inputs and still sets bounds, so it is an accepted technique. > Compound this with the empirical observation > that, beside X and Y, there's U, V, W and many more, and there you > have it. There is no such empirical observation. That windmill in front of you is not a dragon. > Add a sprinkle of a volatile environment, as well as > differing environments, because one code base might run in all sorts > of them... > > A simple answer to this is to (strive to ;-)) handle OOM gracefully. > Even if anything you'd just wrote were true, you're still making the case for handling OOM by termination in reality. If the environment were really as diverse and volatile as you claim, and I can't prevent the condition by setting reasonable bounds, there's really no reason to believe I can respond to the condition after the fact, either. Adam
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-09-07 00:08 -0700 |
| Message-ID | <c46b879f-4198-4f1a-a504-bbcf05ec8f12@k9g2000vbd.googlegroups.com> |
| In reply to | #9789 |
On Sep 6, 12:04 pm, Adam Skutt <ask...@gmail.com> wrote: > On Sep 6, 3:12 am, Goran <goran.pu...@gmail.com> wrote: > > > > > > > > > > > On Sep 6, 3:50 am, Adam Skutt <ask...@gmail.com> wrote: > > > > On Sep 4, 1:56 pm, James Kanze <james.ka...@gmail.com> wrote: > > > > > On Sep 4, 1:03 am, Ian Collins <ian-n...@hotmail.com> wrote: > > > > > > On 09/ 4/11 11:20 AM, James Kanze wrote: > > > > > > On Sep 2, 6:45 am, Ian Collins<ian-n...@hotmail.com> wrote: > > > > > >> On 09/ 2/11 04:37 PM, Adam Skutt wrote: > > > > > > [...] > > > > > >> I agree. On a descent hosted environment, memory exhaustion is usually > > > > > >> down to either a system wide problem, or a programming error. > > > > > > Or an overly complex client request. > > > > > Not spotting those is a programming (or specification) error! > > > > > And the way you spot them is by catching bad_alloc:-). > > > > No, you set upfront bounds on allowable inputs. This is what other > > > engineering disciplines do, so I'm not sure why computer programmers > > > would do something different. > > > Because code runs in a more volatile environment > > It does nothing of the sort! Code does not have to deal the physical > environment: it doesn't have to be concerned with the external > temperature, humidity, shock, weather conditions, etc. It does not > care whether the computer has been placed in a server room or outside > in the middle of the desert. Hardware frequently has to care about > all of these factors, and many more. Operating systems provide > reasonable levels of isolation between components: software can > generally ignore the other software running on the same computer. > Hardware design has to frequently care about these factors: the mere > placement of ICs on a board can cause them to interfere with one > another! > > The list goes on and on, and applies to all of the other engineering > disciplines too. This is easily by far both the most absurd and most > ignorant thing you've said yet, by a mile. > > > and tends to handle > > more complex (models of) systems. > > Because it's cheaper and easier to do such things in software, in no > small part because many of the classical design considerations for > hardware simply disappear. However, that doesn't change my statement > on setting bounds in the least. > > > An obvious example: a program operates on a set of X-es in one part, > > and on a set of Y-s in another. Both are being "added" to operation as > > user goes along. Given system limits, code can operate in a range on A > > X-es and 0 Y-s, or 0 X-es and B Y-s, and any many-a-combination in > > between. Whichever way you decide on a limit on max count of X or Y, > > some use will suffer. > > I'm not sure how you think this is irrelevant to this portion of the > discussion, but it's not even true. The limit for both may be > excessively generous for any reasonable use case. Moreover, plenty of > hardware has to process two distinct inputs and still sets bounds, so > it is an accepted technique. > > > Compound this with the empirical observation > > that, beside X and Y, there's U, V, W and many more, and there you > > have it. > > There is no such empirical observation. Of course there is. Take a look at any non-trivial codebase. There's dozens of types (classes, structures), combining themselves in a myriad of ways. Each of those is instantiated a pretty much unknown amount of times, put into containers, moved around, all sorts of stuff is happening. Do you e.g. limit a number of string objects that can be created in you code? I would like to see that codebase. What the...!?!? Goran.
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-09-07 02:33 -0700 |
| Message-ID | <7c0a8185-9f55-41b0-be7c-75c868302b94@a13g2000yqd.googlegroups.com> |
| In reply to | #9789 |
On Sep 6, 11:04 am, Adam Skutt <ask...@gmail.com> wrote: > On Sep 6, 3:12 am, Goran <goran.pu...@gmail.com> wrote: > > > > > > > On Sep 6, 3:50 am, Adam Skutt <ask...@gmail.com> wrote: > > > > On Sep 4, 1:56 pm, James Kanze <james.ka...@gmail.com> wrote: > > > > > On Sep 4, 1:03 am, Ian Collins <ian-n...@hotmail.com> wrote: > > > > > > On 09/ 4/11 11:20 AM, James Kanze wrote: > > > > > > On Sep 2, 6:45 am, Ian Collins<ian-n...@hotmail.com> wrote: > > > > > >> On 09/ 2/11 04:37 PM, Adam Skutt wrote: > > > > > > [...] > > > > > >> I agree. On a descent hosted environment, memory exhaustion is usually > > > > > >> down to either a system wide problem, or a programming error. > > > > > > Or an overly complex client request. > > > > > Not spotting those is a programming (or specification) error! > > > > > And the way you spot them is by catching bad_alloc:-). > > > > No, you set upfront bounds on allowable inputs. This is what other > > > engineering disciplines do, so I'm not sure why computer programmers > > > would do something different. > > > Because code runs in a more volatile environment > > It does nothing of the sort! Code does not have to deal the physical > environment: it doesn't have to be concerned with the external > temperature, humidity, shock, weather conditions, etc. It does not > care whether the computer has been placed in a server room or outside > in the middle of the desert. Hardware frequently has to care about > all of these factors, and many more. Operating systems provide > reasonable levels of isolation between components: software can > generally ignore the other software running on the same computer. > Hardware design has to frequently care about these factors: the mere > placement of ICs on a board can cause them to interfere with one > another! > > The list goes on and on, and applies to all of the other engineering > disciplines too. This is easily by far both the most absurd and most > ignorant thing you've said yet, by a mile. > > > and tends to handle > > more complex (models of) systems. > > Because it's cheaper and easier to do such things in software, in no > small part because many of the classical design considerations for > hardware simply disappear. However, that doesn't change my statement > on setting bounds in the least. > > > An obvious example: a program operates on a set of X-es in one part, > > and on a set of Y-s in another. Both are being "added" to operation as > > user goes along. Given system limits, code can operate in a range on A > > X-es and 0 Y-s, or 0 X-es and B Y-s, and any many-a-combination in > > between. Whichever way you decide on a limit on max count of X or Y, > > some use will suffer. > > I'm not sure how you think this is irrelevant to this portion of the > discussion, but it's not even true. The limit for both may be > excessively generous for any reasonable use case. Moreover, plenty of > hardware has to process two distinct inputs and still sets bounds, so > it is an accepted technique. > > > Compound this with the empirical observation > > that, beside X and Y, there's U, V, W and many more, and there you > > have it. > > There is no such empirical observation. That windmill in front of you > is not a dragon. > > > Add a sprinkle of a volatile environment, as well as > > differing environments, because one code base might run in all sorts > > of them... > > > A simple answer to this is to (strive to ;-)) handle OOM gracefully. > > Even if anything you'd just wrote were true, you're still making the > case for handling OOM by termination in reality. If the environment > were really as diverse and volatile as you claim, and I can't prevent > the condition by setting reasonable bounds, there's really no reason > to believe I can respond to the condition after the fact, either. rather tahn wait for OOM you could detect low memory conditions and take evasive action (eg. reject any furthur requests and concentrate on the ones you've got.
[toc] | [prev] | [next] | [standalone]
| From | Adam Skutt <askutt@gmail.com> |
|---|---|
| Date | 2011-09-07 04:28 -0700 |
| Message-ID | <66af4f93-c372-41e6-9e0a-f55366d1093a@o15g2000vbe.googlegroups.com> |
| In reply to | #9878 |
On Sep 7, 5:33 am, Nick Keighley <nick_keighley_nos...@hotmail.com> wrote: > On Sep 6, 11:04 am, Adam Skutt <ask...@gmail.com> wrote: > > On Sep 6, 3:12 am, Goran <goran.pu...@gmail.com> wrote: > > > A simple answer to this is to (strive to ;-)) handle OOM gracefully. > > > Even if anything you'd just wrote were true, you're still making the > > case for handling OOM by termination in reality. If the environment > > were really as diverse and volatile as you claim, and I can't prevent > > the condition by setting reasonable bounds, there's really no reason > > to believe I can respond to the condition after the fact, either. > > rather tahn wait for OOM you could detect low memory conditions and > take evasive action (eg. reject any furthur requests and concentrate > on the ones you've got. If it were possible to reliably detect low memory conditions then I don't think we'd be having this discussion at all. No, generally the only way to find out if you can allocate memory is to try it. Adam
[toc] | [prev] | [next] | [standalone]
| From | yatremblay@bel1lin202.(none) (Yannick Tremblay) |
|---|---|
| Date | 2011-09-06 13:43 +0000 |
| Message-ID | <j4581n$l3h$1@dont-email.me> |
| In reply to | #9773 |
In article <2ab097e7-57e7-4e01-9d05-5630fe255646@f41g2000yqh.googlegroups.com>, Adam Skutt <askutt@gmail.com> wrote: >On Sep 4, 1:56pm, James Kanze <james.ka...@gmail.com> wrote: >> On Sep 4, 1:03 am, Ian Collins <ian-n...@hotmail.com> wrote: >> >> > On 09/ 4/11 11:20 AM, James Kanze wrote: >> > > On Sep 2, 6:45 am, Ian Collins<ian-n...@hotmail.com> wrote: >> > >> On 09/ 2/11 04:37 PM, Adam Skutt wrote: >> > > [...] >> > >> I agree. On a descent hosted environment, memory exhaustion is usually >> > >> down to either a system wide problem, or a programming error. >> > > Or an overly complex client request. >> > Not spotting those is a programming (or specification) error! >> >> And the way you spot them is by catching bad_alloc:-). >> > >No, you set upfront bounds on allowable inputs. This is what other >engineering disciplines do, so I'm not sure why computer programmers >would do something different. Algorithms that permit bounded response >to unbounded input are pretty rare in the grand scheme of things. >Even when they exist, they may carry tradeoffs that make them >undesirable or unsuitable (e.g., internal vs. external sort). So, if I understand you correctly, you are saying that you must always setup some artificial limits to the external inputs and set artificially low so that no matter what is happening in the rest of the system, the program will never run out of resources.... This seems like a very bad proposition to me. The only way to win is to reserve and grab at startup time all of the resources you might potentially ever need in order to meet the worse case scenario of your inputs. Yannick
[toc] | [prev] | [next] | [standalone]
| From | Paul <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-09-06 07:37 -0700 |
| Message-ID | <c97833a6-3895-4211-91a0-b679057bffe0@d2g2000vby.googlegroups.com> |
| In reply to | #9799 |
On Sep 6, 2:43 pm, yatremblay@bel1lin202.(none) (Yannick Tremblay) wrote: > In article <2ab097e7-57e7-4e01-9d05-5630fe255...@f41g2000yqh.googlegroups.com>, > Adam Skutt <ask...@gmail.com> wrote: > > > > > > >On Sep 4, 1:56pm, James Kanze <james.ka...@gmail.com> wrote: > >> On Sep 4, 1:03 am, Ian Collins <ian-n...@hotmail.com> wrote: > > >> > On 09/ 4/11 11:20 AM, James Kanze wrote: > >> > > On Sep 2, 6:45 am, Ian Collins<ian-n...@hotmail.com> wrote: > >> > >> On 09/ 2/11 04:37 PM, Adam Skutt wrote: > >> > > [...] > >> > >> I agree. On a descent hosted environment, memory exhaustion is usually > >> > >> down to either a system wide problem, or a programming error. > >> > > Or an overly complex client request. > >> > Not spotting those is a programming (or specification) error! > > >> And the way you spot them is by catching bad_alloc:-). > > >No, you set upfront bounds on allowable inputs. This is what other > >engineering disciplines do, so I'm not sure why computer programmers > >would do something different. Algorithms that permit bounded response > >to unbounded input are pretty rare in the grand scheme of things. > >Even when they exist, they may carry tradeoffs that make them > >undesirable or unsuitable (e.g., internal vs. external sort). > > So, if I understand you correctly, you are saying that you must always > setup some artificial limits to the external inputs and set > artificially low so that no matter what is happening in the rest of > the system, the program will never run out of resources.... > > This seems like a very bad proposition to me. The only way to win is > to reserve and grab at startup time all of the resources you might > potentially ever need in order to meet the worse case scenario of your > inputs. > This is not possilbe in the situation where a program is limited by system memory. As a crude example a text editor opening a new window to display each text file, the number of windows is limited by available system RAM. The type of program you describe is not limited by system RAM, it is limited the procedures it executes.. for example Freecell or Minesweeper are limited in the amount of RAM they can consume. I think this is why programs specify system requirments, but many games and stuff specify it as a minimum and suggest that much better performance will be achieved if more RAM is available. The language provides us with a mechanism to catch errors and I don't know why people shun it. I think it has a lot to do with laziness TBH.
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-09-07 00:11 -0700 |
| Message-ID | <9fa3e919-032c-475d-8a7a-9b6ae927b9bd@dp9g2000vbb.googlegroups.com> |
| In reply to | #9804 |
On Sep 6, 4:37 pm, Paul <pchris...@yahoo.co.uk> wrote: > On Sep 6, 2:43 pm, yatremblay@bel1lin202.(none) (Yannick Tremblay) > wrote: > > > > > > > > > In article <2ab097e7-57e7-4e01-9d05-5630fe255...@f41g2000yqh.googlegroups.com>, > > Adam Skutt <ask...@gmail.com> wrote: > > > >On Sep 4, 1:56pm, James Kanze <james.ka...@gmail.com> wrote: > > >> On Sep 4, 1:03 am, Ian Collins <ian-n...@hotmail.com> wrote: > > > >> > On 09/ 4/11 11:20 AM, James Kanze wrote: > > >> > > On Sep 2, 6:45 am, Ian Collins<ian-n...@hotmail.com> wrote: > > >> > >> On 09/ 2/11 04:37 PM, Adam Skutt wrote: > > >> > > [...] > > >> > >> I agree. On a descent hosted environment, memory exhaustion is usually > > >> > >> down to either a system wide problem, or a programming error. > > >> > > Or an overly complex client request. > > >> > Not spotting those is a programming (or specification) error! > > > >> And the way you spot them is by catching bad_alloc:-). > > > >No, you set upfront bounds on allowable inputs. This is what other > > >engineering disciplines do, so I'm not sure why computer programmers > > >would do something different. Algorithms that permit bounded response > > >to unbounded input are pretty rare in the grand scheme of things. > > >Even when they exist, they may carry tradeoffs that make them > > >undesirable or unsuitable (e.g., internal vs. external sort). > > > So, if I understand you correctly, you are saying that you must always > > setup some artificial limits to the external inputs and set > > artificially low so that no matter what is happening in the rest of > > the system, the program will never run out of resources.... > > > This seems like a very bad proposition to me. The only way to win is > > to reserve and grab at startup time all of the resources you might > > potentially ever need in order to meet the worse case scenario of your > > inputs. > > This is not possilbe in the situation where a program is limited by > system memory. As a crude example a text editor opening a new window > to display each text file, the number of windows is limited by > available system RAM. Not at all. Say that you simply load said text into memory (crude approach, works for a massive amount of uses). If the file is 3 bytes, chances are, you'll open thousands. If the file is a couple of megs, you won't get there. Goran.
[toc] | [prev] | [next] | [standalone]
| From | Paul <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-09-07 04:29 -0700 |
| Message-ID | <a8bd30c7-f902-421d-a1d9-8a4461be3b7b@f41g2000yqh.googlegroups.com> |
| In reply to | #9871 |
On Sep 7, 8:11 am, Goran <goran.pu...@gmail.com> wrote: > On Sep 6, 4:37 pm, Paul <pchris...@yahoo.co.uk> wrote: > > > > > > > On Sep 6, 2:43 pm, yatremblay@bel1lin202.(none) (Yannick Tremblay) > > wrote: > > > > In article <2ab097e7-57e7-4e01-9d05-5630fe255...@f41g2000yqh.googlegroups.com>, > > > Adam Skutt <ask...@gmail.com> wrote: > > > > >On Sep 4, 1:56pm, James Kanze <james.ka...@gmail.com> wrote: > > > >> On Sep 4, 1:03 am, Ian Collins <ian-n...@hotmail.com> wrote: > > > > >> > On 09/ 4/11 11:20 AM, James Kanze wrote: > > > >> > > On Sep 2, 6:45 am, Ian Collins<ian-n...@hotmail.com> wrote: > > > >> > >> On 09/ 2/11 04:37 PM, Adam Skutt wrote: > > > >> > > [...] > > > >> > >> I agree. On a descent hosted environment, memory exhaustion is usually > > > >> > >> down to either a system wide problem, or a programming error. > > > >> > > Or an overly complex client request. > > > >> > Not spotting those is a programming (or specification) error! > > > > >> And the way you spot them is by catching bad_alloc:-). > > > > >No, you set upfront bounds on allowable inputs. This is what other > > > >engineering disciplines do, so I'm not sure why computer programmers > > > >would do something different. Algorithms that permit bounded response > > > >to unbounded input are pretty rare in the grand scheme of things. > > > >Even when they exist, they may carry tradeoffs that make them > > > >undesirable or unsuitable (e.g., internal vs. external sort). > > > > So, if I understand you correctly, you are saying that you must always > > > setup some artificial limits to the external inputs and set > > > artificially low so that no matter what is happening in the rest of > > > the system, the program will never run out of resources.... > > > > This seems like a very bad proposition to me. The only way to win is > > > to reserve and grab at startup time all of the resources you might > > > potentially ever need in order to meet the worse case scenario of your > > > inputs. > > > This is not possilbe in the situation where a program is limited by > > system memory. As a crude example a text editor opening a new window > > to display each text file, the number of windows is limited by > > available system RAM. > > Not at all. Say that you simply load said text into memory (crude > approach, works for a massive amount of uses). If the file is 3 bytes, > chances are, you'll open thousands. If the file is a couple of megs, > you won't get there. > But if the file size is unknown until say a user selects from a dailog window. You can't predict how many buffers and what size each buffer will need to be. The only way this system can really work is if you grab a memory pool and then have some kind of allocation handler that processes allocation/deallocation from the pool. I don't know how you would know the size of this pool to initially grab. Perhaps a trial and error until a bad alloc is thrown . :)
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-09-07 05:38 -0700 |
| Message-ID | <c22bd130-1554-4f24-9eb9-6dfb3f13964f@u26g2000yqu.googlegroups.com> |
| In reply to | #9893 |
On Sep 7, 1:29 pm, Paul <pchris...@yahoo.co.uk> wrote:
> On Sep 7, 8:11 am, Goran <goran.pu...@gmail.com> wrote:
>
>
>
>
>
>
>
> > On Sep 6, 4:37 pm, Paul <pchris...@yahoo.co.uk> wrote:
>
> > > On Sep 6, 2:43 pm, yatremblay@bel1lin202.(none) (Yannick Tremblay)
> > > wrote:
>
> > > > In article <2ab097e7-57e7-4e01-9d05-5630fe255...@f41g2000yqh.googlegroups.com>,
> > > > Adam Skutt <ask...@gmail.com> wrote:
>
> > > > >On Sep 4, 1:56pm, James Kanze <james.ka...@gmail.com> wrote:
> > > > >> On Sep 4, 1:03 am, Ian Collins <ian-n...@hotmail.com> wrote:
>
> > > > >> > On 09/ 4/11 11:20 AM, James Kanze wrote:
> > > > >> > > On Sep 2, 6:45 am, Ian Collins<ian-n...@hotmail.com> wrote:
> > > > >> > >> On 09/ 2/11 04:37 PM, Adam Skutt wrote:
> > > > >> > > [...]
> > > > >> > >> I agree. On a descent hosted environment, memory exhaustion is usually
> > > > >> > >> down to either a system wide problem, or a programming error.
> > > > >> > > Or an overly complex client request.
> > > > >> > Not spotting those is a programming (or specification) error!
>
> > > > >> And the way you spot them is by catching bad_alloc:-).
>
> > > > >No, you set upfront bounds on allowable inputs. This is what other
> > > > >engineering disciplines do, so I'm not sure why computer programmers
> > > > >would do something different. Algorithms that permit bounded response
> > > > >to unbounded input are pretty rare in the grand scheme of things.
> > > > >Even when they exist, they may carry tradeoffs that make them
> > > > >undesirable or unsuitable (e.g., internal vs. external sort).
>
> > > > So, if I understand you correctly, you are saying that you must always
> > > > setup some artificial limits to the external inputs and set
> > > > artificially low so that no matter what is happening in the rest of
> > > > the system, the program will never run out of resources....
>
> > > > This seems like a very bad proposition to me. The only way to win is
> > > > to reserve and grab at startup time all of the resources you might
> > > > potentially ever need in order to meet the worse case scenario of your
> > > > inputs.
>
> > > This is not possilbe in the situation where a program is limited by
> > > system memory. As a crude example a text editor opening a new window
> > > to display each text file, the number of windows is limited by
> > > available system RAM.
>
> > Not at all. Say that you simply load said text into memory (crude
> > approach, works for a massive amount of uses). If the file is 3 bytes,
> > chances are, you'll open thousands. If the file is a couple of megs,
> > you won't get there.
>
> But if the file size is unknown until say a user selects from a dailog
> window.
> You can't predict how many buffers and what size each buffer will need
> to be.
>
> The only way this system can really work is if you grab a memory pool
> and then have some kind of allocation handler that processes
> allocation/deallocation from the pool.
> I don't know how you would know the size of this pool to initially
> grab. Perhaps a trial and error until a bad alloc is thrown . :)
Sorry, I poorly explained myself there. I was arguing with something
that wasn't written.
What I wanted to say is that the number of windows you'll get to open
will vary wildly depending on the file size. I agree that one you
can't predict anything.
Therefore, the best (and simplest if you ask me) way to proceed is to
try to allocate and do __not__ "handle" bad_alloc. I pretty much agree
with Skutt that "handling" OOM is impossible, especially not at the
spot where it occurred, because memory is possibly tightest there. In
the imaginary editor, imagine sequence of events:
ask the user which file to open
create "frame" window for the file
create, I dunno, borders, toolbar, whatever
create widget to host text
load the text (say, whole file into a buffer that you pass to the
widget for display)
In pseudo-C++, that might be:
auto_ptr<Frame> openFile(const char* name)
{
auto_ptr<Frame> frame = new Frame();
frame->Decorate();
EditorWidget& e = frame->GetEditor();
vector<char> text = LoadFile(name);
e.SetText(text);
}
In the above, you allocate all sorts of stuff: frame, "decorations",
editor widget inside the frame. (I presume that frame "owns" that, and
GetEditor creates actual EditorWidget e.g. on demand, therefore it
gives it out as a reference). I also presume that LoadFile is a
function that loads a file into vector<char>. I presume that any
function you see throw an exception in case of any problems.
I say that the above code is resilient to resource shortage, and that,
if there is a resource shortage at any point bar "new Frame()" line,
it will nicely clean up behind and leave with at least some resources.
You can call this as much as you like and you'll be fine. No arena
allocators, no pools, no try/catch, no nothing. I further say that C++
makes it +/- easy to write similarly correct code.
Finally, I say: boy did I go off the tangent here...
Goran.
[toc] | [prev] | [next] | [standalone]
| From | Paul <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-09-07 18:17 -0700 |
| Message-ID | <20307d83-0caf-4488-a573-2d7e1811bf4e@m18g2000vbe.googlegroups.com> |
| In reply to | #9905 |
On Sep 7, 1:38 pm, Goran <goran.pu...@gmail.com> wrote:
> On Sep 7, 1:29 pm, Paul <pchris...@yahoo.co.uk> wrote:
>
>
>
>
>
> > On Sep 7, 8:11 am, Goran <goran.pu...@gmail.com> wrote:
>
> > > On Sep 6, 4:37 pm, Paul <pchris...@yahoo.co.uk> wrote:
>
> > > > On Sep 6, 2:43 pm, yatremblay@bel1lin202.(none) (Yannick Tremblay)
> > > > wrote:
>
> > > > > In article <2ab097e7-57e7-4e01-9d05-5630fe255...@f41g2000yqh.googlegroups.com>,
> > > > > Adam Skutt <ask...@gmail.com> wrote:
>
> > > > > >On Sep 4, 1:56pm, James Kanze <james.ka...@gmail.com> wrote:
> > > > > >> On Sep 4, 1:03 am, Ian Collins <ian-n...@hotmail.com> wrote:
>
> > > > > >> > On 09/ 4/11 11:20 AM, James Kanze wrote:
> > > > > >> > > On Sep 2, 6:45 am, Ian Collins<ian-n...@hotmail.com> wrote:
> > > > > >> > >> On 09/ 2/11 04:37 PM, Adam Skutt wrote:
> > > > > >> > > [...]
> > > > > >> > >> I agree. On a descent hosted environment, memory exhaustion is usually
> > > > > >> > >> down to either a system wide problem, or a programming error.
> > > > > >> > > Or an overly complex client request.
> > > > > >> > Not spotting those is a programming (or specification) error!
>
> > > > > >> And the way you spot them is by catching bad_alloc:-).
>
> > > > > >No, you set upfront bounds on allowable inputs. This is what other
> > > > > >engineering disciplines do, so I'm not sure why computer programmers
> > > > > >would do something different. Algorithms that permit bounded response
> > > > > >to unbounded input are pretty rare in the grand scheme of things.
> > > > > >Even when they exist, they may carry tradeoffs that make them
> > > > > >undesirable or unsuitable (e.g., internal vs. external sort).
>
> > > > > So, if I understand you correctly, you are saying that you must always
> > > > > setup some artificial limits to the external inputs and set
> > > > > artificially low so that no matter what is happening in the rest of
> > > > > the system, the program will never run out of resources....
>
> > > > > This seems like a very bad proposition to me. The only way to win is
> > > > > to reserve and grab at startup time all of the resources you might
> > > > > potentially ever need in order to meet the worse case scenario of your
> > > > > inputs.
>
> > > > This is not possilbe in the situation where a program is limited by
> > > > system memory. As a crude example a text editor opening a new window
> > > > to display each text file, the number of windows is limited by
> > > > available system RAM.
>
> > > Not at all. Say that you simply load said text into memory (crude
> > > approach, works for a massive amount of uses). If the file is 3 bytes,
> > > chances are, you'll open thousands. If the file is a couple of megs,
> > > you won't get there.
>
> > But if the file size is unknown until say a user selects from a dailog
> > window.
> > You can't predict how many buffers and what size each buffer will need
> > to be.
>
> > The only way this system can really work is if you grab a memory pool
> > and then have some kind of allocation handler that processes
> > allocation/deallocation from the pool.
> > I don't know how you would know the size of this pool to initially
> > grab. Perhaps a trial and error until a bad alloc is thrown . :)
>
> Sorry, I poorly explained myself there. I was arguing with something
> that wasn't written.
>
> What I wanted to say is that the number of windows you'll get to open
> will vary wildly depending on the file size. I agree that one you
> can't predict anything.
>
> Therefore, the best (and simplest if you ask me) way to proceed is to
> try to allocate and do __not__ "handle" bad_alloc. I pretty much agree
> with Skutt that "handling" OOM is impossible, especially not at the
> spot where it occurred, because memory is possibly tightest there. In
> the imaginary editor, imagine sequence of events:
>
> ask the user which file to open
> create "frame" window for the file
> create, I dunno, borders, toolbar, whatever
> create widget to host text
> load the text (say, whole file into a buffer that you pass to the
> widget for display)
>
> In pseudo-C++, that might be:
>
> auto_ptr<Frame> openFile(const char* name)
> {
> auto_ptr<Frame> frame = new Frame();
> frame->Decorate();
> EditorWidget& e = frame->GetEditor();
> vector<char> text = LoadFile(name);
> e.SetText(text);
>
> }
>
> In the above, you allocate all sorts of stuff: frame, "decorations",
> editor widget inside the frame. (I presume that frame "owns" that, and
> GetEditor creates actual EditorWidget e.g. on demand, therefore it
> gives it out as a reference). I also presume that LoadFile is a
> function that loads a file into vector<char>. I presume that any
> function you see throw an exception in case of any problems.
>
> I say that the above code is resilient to resource shortage, and that,
> if there is a resource shortage at any point bar "new Frame()" line,
> it will nicely clean up behind and leave with at least some resources.
> You can call this as much as you like and you'll be fine. No arena
> allocators, no pools, no try/catch, no nothing. I further say that C++
> makes it +/- easy to write similarly correct code.
>
> Finally, I say: boy did I go off the tangent here...
>
Well TBH I don't know WTF you are talking about bu if you had such an
app I would think the sensible resolution would be to stop opening
windows. Display a message to user and say no more windows until you
close some.
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-09-08 00:45 -0700 |
| Message-ID | <737875f6-2b27-44b8-9e9a-c9e79e23fd5b@e9g2000yqb.googlegroups.com> |
| In reply to | #9912 |
On Sep 8, 3:17 am, Paul <pchris...@yahoo.co.uk> wrote:
> On Sep 7, 1:38 pm, Goran <goran.pu...@gmail.com> wrote:
>
>
>
>
>
>
>
> > On Sep 7, 1:29 pm, Paul <pchris...@yahoo.co.uk> wrote:
>
> > > On Sep 7, 8:11 am, Goran <goran.pu...@gmail.com> wrote:
>
> > > > On Sep 6, 4:37 pm, Paul <pchris...@yahoo.co.uk> wrote:
>
> > > > > On Sep 6, 2:43 pm, yatremblay@bel1lin202.(none) (Yannick Tremblay)
> > > > > wrote:
>
> > > > > > In article <2ab097e7-57e7-4e01-9d05-5630fe255...@f41g2000yqh.googlegroups.com>,
> > > > > > Adam Skutt <ask...@gmail.com> wrote:
>
> > > > > > >On Sep 4, 1:56pm, James Kanze <james.ka...@gmail.com> wrote:
> > > > > > >> On Sep 4, 1:03 am, Ian Collins <ian-n...@hotmail.com> wrote:
>
> > > > > > >> > On 09/ 4/11 11:20 AM, James Kanze wrote:
> > > > > > >> > > On Sep 2, 6:45 am, Ian Collins<ian-n...@hotmail.com> wrote:
> > > > > > >> > >> On 09/ 2/11 04:37 PM, Adam Skutt wrote:
> > > > > > >> > > [...]
> > > > > > >> > >> I agree. On a descent hosted environment, memory exhaustion is usually
> > > > > > >> > >> down to either a system wide problem, or a programming error.
> > > > > > >> > > Or an overly complex client request.
> > > > > > >> > Not spotting those is a programming (or specification) error!
>
> > > > > > >> And the way you spot them is by catching bad_alloc:-).
>
> > > > > > >No, you set upfront bounds on allowable inputs. This is what other
> > > > > > >engineering disciplines do, so I'm not sure why computer programmers
> > > > > > >would do something different. Algorithms that permit bounded response
> > > > > > >to unbounded input are pretty rare in the grand scheme of things.
> > > > > > >Even when they exist, they may carry tradeoffs that make them
> > > > > > >undesirable or unsuitable (e.g., internal vs. external sort).
>
> > > > > > So, if I understand you correctly, you are saying that you must always
> > > > > > setup some artificial limits to the external inputs and set
> > > > > > artificially low so that no matter what is happening in the rest of
> > > > > > the system, the program will never run out of resources....
>
> > > > > > This seems like a very bad proposition to me. The only way to win is
> > > > > > to reserve and grab at startup time all of the resources you might
> > > > > > potentially ever need in order to meet the worse case scenario of your
> > > > > > inputs.
>
> > > > > This is not possilbe in the situation where a program is limited by
> > > > > system memory. As a crude example a text editor opening a new window
> > > > > to display each text file, the number of windows is limited by
> > > > > available system RAM.
>
> > > > Not at all. Say that you simply load said text into memory (crude
> > > > approach, works for a massive amount of uses). If the file is 3 bytes,
> > > > chances are, you'll open thousands. If the file is a couple of megs,
> > > > you won't get there.
>
> > > But if the file size is unknown until say a user selects from a dailog
> > > window.
> > > You can't predict how many buffers and what size each buffer will need
> > > to be.
>
> > > The only way this system can really work is if you grab a memory pool
> > > and then have some kind of allocation handler that processes
> > > allocation/deallocation from the pool.
> > > I don't know how you would know the size of this pool to initially
> > > grab. Perhaps a trial and error until a bad alloc is thrown . :)
>
> > Sorry, I poorly explained myself there. I was arguing with something
> > that wasn't written.
>
> > What I wanted to say is that the number of windows you'll get to open
> > will vary wildly depending on the file size. I agree that one you
> > can't predict anything.
>
> > Therefore, the best (and simplest if you ask me) way to proceed is to
> > try to allocate and do __not__ "handle" bad_alloc. I pretty much agree
> > with Skutt that "handling" OOM is impossible, especially not at the
> > spot where it occurred, because memory is possibly tightest there. In
> > the imaginary editor, imagine sequence of events:
>
> > ask the user which file to open
> > create "frame" window for the file
> > create, I dunno, borders, toolbar, whatever
> > create widget to host text
> > load the text (say, whole file into a buffer that you pass to the
> > widget for display)
>
> > In pseudo-C++, that might be:
>
> > auto_ptr<Frame> openFile(const char* name)
> > {
> > auto_ptr<Frame> frame = new Frame();
> > frame->Decorate();
> > EditorWidget& e = frame->GetEditor();
> > vector<char> text = LoadFile(name);
> > e.SetText(text);
>
> > }
>
> > In the above, you allocate all sorts of stuff: frame, "decorations",
> > editor widget inside the frame. (I presume that frame "owns" that, and
> > GetEditor creates actual EditorWidget e.g. on demand, therefore it
> > gives it out as a reference). I also presume that LoadFile is a
> > function that loads a file into vector<char>. I presume that any
> > function you see throw an exception in case of any problems.
>
> > I say that the above code is resilient to resource shortage, and that,
> > if there is a resource shortage at any point bar "new Frame()" line,
> > it will nicely clean up behind and leave with at least some resources.
> > You can call this as much as you like and you'll be fine. No arena
> > allocators, no pools, no try/catch, no nothing. I further say that C++
> > makes it +/- easy to write similarly correct code.
>
> > Finally, I say: boy did I go off the tangent here...
>
> Well TBH I don't know WTF you are talking about bu if you had such an
> app I would think the sensible resolution would be to stop opening
> windows. Display a message to user and say no more windows until you
> close some.
I'll try to clarify (my snippet is full of presumptions, I thought
they were +/- obvious; I am pretty much certain they are reasonable).
Suppose that this app has a "generic" exception handler (UI toolkits
do have such a thing in their UI-handling message loops). Typically,
said loop would receive a command-type message ("open a file") from
the user. That would end up in some function that asks for the file
name and then, possibly, my openFile would get called. Say that
openFile should return a pointer to a "Frame" (window) object that
displays the file.
So what happens if something, anything, goes wrong in openFile? Well,
nothing bad. Exception is thrown, hopefully containing, one way or
another, info on what has gone wrong. See that auto_ptr<Frame> there?
That ensures that, if exception is thrown, newly allocated Frame
instance will be deleted. See that vector<char> returned by LoadFile?
That ensures that, whatever storage might have been allocated for file
contents, will be freed. I claim: similar logic can be +/- trivially
applied to any bit of code for it to be error-resilient (a.k.a.
exception-safe).
About your "no more windows until you close some" idea: there's no
__need__ for that. What if file was too big for the current system
state, and what if user could open a smaller one? There's no __need__
to prevent further file opening, because:
1. there is __no__ harm in tying
2. some other file might open fine.
Key thing here, and has been, from the very start: exception safety
guarantees of any bit of code must be correct. For example, the
openFile function has "strong" exception guarantee: either it works as
described, either there has been an error an any temporary changes
that might have been made to the program were rolled back (e.g.
allocated Frame, EditorWidget, file contents buffer were all freed).
C++, in particular, offers enough mechanisms to make writing code,
well-designed WRT exception safety guarantees, a reasonably easy
affair.
Goran.
[toc] | [prev] | [next] | [standalone]
| From | Adam Skutt <askutt@gmail.com> |
|---|---|
| Date | 2011-09-06 06:58 -0700 |
| Message-ID | <b5f2c1fd-e60f-43ca-bcf0-88a9ba5a7f42@e8g2000vbc.googlegroups.com> |
| In reply to | #9799 |
On Sep 6, 9:43 am, yatremblay@bel1lin202.(none) (Yannick Tremblay) wrote: > In article <2ab097e7-57e7-4e01-9d05-5630fe255...@f41g2000yqh.googlegroups.com>, > Adam Skutt <ask...@gmail.com> wrote: > So, if I understand you correctly, you are saying that you must always > setup some artificial limits to the external inputs and set > artificially low so that no matter what is happening in the rest of > the system, the program will never run out of resources.... Yes, if you want to isolate failure processing one request from another (esp. in a threaded system), you set limits on how much input can be provided with each request. You reject requests that exceed the limit. However, this doesn't mean the limits are set artificially low. Usually memory isn't your bounding constraint, so you'll run out of database handles, CPU, etc. long before you run out of memory. Per- request memory limits can be generous and not create an issue. Of course, I'm personally fine with unbounded input as long as the user understands the system will break at some point and they get to keep both of the pieces. > This seems like a very bad proposition to me. The only way to win is > to reserve and grab at startup time all of the resources you might > potentially ever need in order to meet the worse case scenario of your > inputs. No, I'm not sure why you think this follows in the least. I also think I've explained why this isn't the case several times already. If you have per-request bounds and the OS can't give you memory when you ask for it you either need to rewrite your code (so you'll be terminating anyway) or the OS is likely to terminate (so you'll be terminating anyway). Adam
[toc] | [prev] | [next] | [standalone]
| From | Paul <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-09-06 09:21 -0700 |
| Message-ID | <25237f35-8c47-4bfc-b769-43a67b9f2e79@c29g2000yqd.googlegroups.com> |
| In reply to | #9807 |
On Sep 6, 2:58 pm, Adam Skutt <ask...@gmail.com> wrote: > On Sep 6, 9:43 am, yatremblay@bel1lin202.(none) (Yannick Tremblay) > wrote: > > > In article <2ab097e7-57e7-4e01-9d05-5630fe255...@f41g2000yqh.googlegroups.com>, > > Adam Skutt <ask...@gmail.com> wrote: > > So, if I understand you correctly, you are saying that you must always > > setup some artificial limits to the external inputs and set > > artificially low so that no matter what is happening in the rest of > > the system, the program will never run out of resources.... > > Yes, if you want to isolate failure processing one request from > another (esp. in a threaded system), you set limits on how much input > can be provided with each request. You reject requests that exceed > the limit. > > However, this doesn't mean the limits are set artificially low. > Usually memory isn't your bounding constraint, so you'll run out of > database handles, CPU, etc. long before you run out of memory. Per- > request memory limits can be generous and not create an issue. > > Of course, I'm personally fine with unbounded input as long as the > user understands the system will break at some point and they get to > keep both of the pieces. > > > This seems like a very bad proposition to me. The only way to win is > > to reserve and grab at startup time all of the resources you might > > potentially ever need in order to meet the worse case scenario of your > > inputs. > > No, I'm not sure why you think this follows in the least. I also > think I've explained why this isn't the case several times already. > If you have per-request bounds and the OS can't give you memory when > you ask for it you either need to rewrite your code (so you'll be > terminating anyway) or the OS is likely to terminate (so you'll be > terminating anyway). > I used play World of Warcraft and my system would sometimes become slow and sluggish, when I added more RAM the game ran much faster and smoother. These programs must be designed in such a way that they operate using the maximum resources without crashing. If termination was the answer I wouldn't have been able to play this game, prior to upgrading my RAM, without it crashing all the time. It didn't crash it played ok but became a bit slow when resources were low.
[toc] | [prev] | [next] | [standalone]
| From | "Fred Zwarts \(KVI\)" <F.Zwarts@KVI.nl> |
|---|---|
| Date | 2011-09-07 09:10 +0200 |
| Message-ID | <j475dd$6l9$1@news.albasani.net> |
| In reply to | #9809 |
"Paul" wrote in message news:25237f35-8c47-4bfc-b769-43a67b9f2e79@c29g2000yqd.googlegroups.com... > >On Sep 6, 2:58 pm, Adam Skutt <ask...@gmail.com> wrote: >> On Sep 6, 9:43 am, yatremblay@bel1lin202.(none) (Yannick Tremblay) >> wrote: >> >> > In article >> > <2ab097e7-57e7-4e01-9d05-5630fe255...@f41g2000yqh.googlegroups.com>, >> > Adam Skutt <ask...@gmail.com> wrote: >> > So, if I understand you correctly, you are saying that you must always >> > setup some artificial limits to the external inputs and set >> > artificially low so that no matter what is happening in the rest of >> > the system, the program will never run out of resources.... >> >> Yes, if you want to isolate failure processing one request from >> another (esp. in a threaded system), you set limits on how much input >> can be provided with each request. You reject requests that exceed >> the limit. >> >> However, this doesn't mean the limits are set artificially low. >> Usually memory isn't your bounding constraint, so you'll run out of >> database handles, CPU, etc. long before you run out of memory. Per- >> request memory limits can be generous and not create an issue. >> >> Of course, I'm personally fine with unbounded input as long as the >> user understands the system will break at some point and they get to >> keep both of the pieces. >> >> > This seems like a very bad proposition to me. The only way to win is >> > to reserve and grab at startup time all of the resources you might >> > potentially ever need in order to meet the worse case scenario of your >> > inputs. >> >> No, I'm not sure why you think this follows in the least. I also >> think I've explained why this isn't the case several times already. >> If you have per-request bounds and the OS can't give you memory when >> you ask for it you either need to rewrite your code (so you'll be >> terminating anyway) or the OS is likely to terminate (so you'll be >> terminating anyway). >> >I used play World of Warcraft and my system would sometimes become >slow and sluggish, when I added more RAM the game ran much faster and >smoother. > >These programs must be designed in such a way that they operate using >the maximum resources without crashing. If termination was the answer >I wouldn't have been able to play this game, prior to upgrading my >RAM, without it crashing all the time. It didn't crash it played ok >but became a bit slow when resources were low. This is probably not a design of these programs. They run on a virtual memory OS. If a program does not fit in RAM, OS replaces some RAM with swap space. Swap space is usually hard disk, which is thousand times slower than RAM. If RAM is added, the whole program fits in RAM, which makes it much faster. No design of these programs is needed to use virtual memory, because it is a OS feature, not a program feature.
[toc] | [prev] | [next] | [standalone]
| From | Paul <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-09-07 04:18 -0700 |
| Message-ID | <c4791ac6-2f71-40df-8176-c892719a48b0@a13g2000yqd.googlegroups.com> |
| In reply to | #9870 |
On Sep 7, 8:10 am, "Fred Zwarts \(KVI\)" <F.Zwa...@KVI.nl> wrote: > "Paul" wrote in message > > news:25237f35-8c47-4bfc-b769-43a67b9f2e79@c29g2000yqd.googlegroups.com... > > > > > > > > >On Sep 6, 2:58 pm, Adam Skutt <ask...@gmail.com> wrote: > >> On Sep 6, 9:43 am, yatremblay@bel1lin202.(none) (Yannick Tremblay) > >> wrote: > > >> > In article > >> > <2ab097e7-57e7-4e01-9d05-5630fe255...@f41g2000yqh.googlegroups.com>, > >> > Adam Skutt <ask...@gmail.com> wrote: > >> > So, if I understand you correctly, you are saying that you must always > >> > setup some artificial limits to the external inputs and set > >> > artificially low so that no matter what is happening in the rest of > >> > the system, the program will never run out of resources.... > > >> Yes, if you want to isolate failure processing one request from > >> another (esp. in a threaded system), you set limits on how much input > >> can be provided with each request. You reject requests that exceed > >> the limit. > > >> However, this doesn't mean the limits are set artificially low. > >> Usually memory isn't your bounding constraint, so you'll run out of > >> database handles, CPU, etc. long before you run out of memory. Per- > >> request memory limits can be generous and not create an issue. > > >> Of course, I'm personally fine with unbounded input as long as the > >> user understands the system will break at some point and they get to > >> keep both of the pieces. > > >> > This seems like a very bad proposition to me. The only way to win is > >> > to reserve and grab at startup time all of the resources you might > >> > potentially ever need in order to meet the worse case scenario of your > >> > inputs. > > >> No, I'm not sure why you think this follows in the least. I also > >> think I've explained why this isn't the case several times already. > >> If you have per-request bounds and the OS can't give you memory when > >> you ask for it you either need to rewrite your code (so you'll be > >> terminating anyway) or the OS is likely to terminate (so you'll be > >> terminating anyway). > > >I used play World of Warcraft and my system would sometimes become > >slow and sluggish, when I added more RAM the game ran much faster and > >smoother. > > >These programs must be designed in such a way that they operate using > >the maximum resources without crashing. If termination was the answer > >I wouldn't have been able to play this game, prior to upgrading my > >RAM, without it crashing all the time. It didn't crash it played ok > >but became a bit slow when resources were low. > > This is probably not a design of these programs. They run on a virtual > memory OS. If a program does not fit in RAM, OS replaces some RAM with swap > space. Swap space is usually hard disk, which is thousand times slower than > RAM. If RAM is added, the whole program fits in RAM, which makes it much > faster. No design of these programs is needed to use virtual memory, because > it is a OS feature, not a program feature.- Hide quoted text - > But lets say we have 3 scenarios: 1) 512MB physical RAM + 1GB swap space = 1.5GB total available RAM. 2) 2GB physical RAM + 2GB swap space = 4GB total available RAM. 3) 1.5GB physical RAM + 512MB swap space = 2GB total available RAM. For each of these scenarios the program will have a different amount of memory available for dynamic allocation. I don't know how this works because the OS must reserve memory for other things but lets just say for example; Available within program for dynamic allocation: 1) 0.5GB 2) 2GB 3) 1GB Yes the page swapping thing can be an issue but on a system with 4GB physical RAM and 16MB swap space the page swaping is not the big problem. Even with windows virtual memory paging there is still not an unlimited supply of memory. A program whos performance is restricted by low memory must check for bad allocations or it would crash all the time. low memory = long load time and lots of memory = fast load time. How can it be faster to load more data into more memory?
[toc] | [prev] | [next] | [standalone]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.c++
csiph-web