Groups | Search | Server Info | Login | Register
Groups > comp.lang.ada > #49693
| From | "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> |
|---|---|
| Newsgroups | comp.lang.ada |
| Subject | Re: On absurdity of collections 7.6.1 (11.1/3) |
| Date | 2021-10-01 09:57 +0200 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <sj6f1q$tlp$2@gioia.aioe.org> (permalink) |
| References | <sj1ah7$7kr$1@gioia.aioe.org> <sj4vb7$heh$1@dont-email.me> <sj5127$1bbu$1@gioia.aioe.org> <sj5oui$qt7$1@franka.jacob-sparre.dk> |
On 2021-10-01 03:40, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:sj5127$1bbu$1@gioia.aioe.org... >> On 2021-09-30 20:23, G.B. wrote: >>> On 29.09.21 11:09, Dmitry A. Kazakov wrote: >>>> For Ada programmers who wonder what it is, >>> What's the reasoning behind run-time selection of storage pools? >> >> It happens quite frequently. Here is an example without controlled >> objects, just an illustration of a dynamically selected storage pool. >> >> Consider a JSON parser. It is be an Ada object with a buffer inside which >> size is a discriminant. On top of the buffer sits an arena pool. The parts >> of the parsed JSON object are allocated in the arena. After parsing the >> result can be used until the next parsing that will sweep the arena, no >> Unchecked_Deallocate. >> >> In this case the collection rule will have no effect since JSON objects do >> not require controlled components (or tasks, yet another thing killed by >> the collection). > > To implement an arena pool, you need to use the subpool mechanism (which > does properly handle finalization when you "sweep the pool" as you put it). > Each "arena" is a separate subpool, and you can dump the entire subpool with > Unchecked_Deallocate_Subpool. Not in this case, where all pool is arena. Allocate takes memory from the object's buffer. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
Back to comp.lang.ada | Previous | Next — Previous in thread | Find similar
On absurdity of collections 7.6.1 (11.1/3) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-09-29 11:09 +0200
Re: On absurdity of collections 7.6.1 (11.1/3) Simon Wright <simon@pushface.org> - 2021-09-29 12:05 +0100
Re: On absurdity of collections 7.6.1 (11.1/3) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-09-29 13:20 +0200
Re: On absurdity of collections 7.6.1 (11.1/3) Simon Wright <simon@pushface.org> - 2021-09-29 22:38 +0100
Re: On absurdity of collections 7.6.1 (11.1/3) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-09-30 10:07 +0200
Re: On absurdity of collections 7.6.1 (11.1/3) Simon Wright <simon@pushface.org> - 2021-09-30 09:35 +0100
Re: On absurdity of collections 7.6.1 (11.1/3) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-09-30 10:49 +0200
Re: On absurdity of collections 7.6.1 (11.1/3) "Randy Brukardt" <randy@rrsoftware.com> - 2021-09-30 20:37 -0500
Re: On absurdity of collections 7.6.1 (11.1/3) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-10-01 09:57 +0200
Re: On absurdity of collections 7.6.1 (11.1/3) "Randy Brukardt" <randy@rrsoftware.com> - 2021-09-29 19:23 -0500
Re: On absurdity of collections 7.6.1 (11.1/3) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-09-30 10:06 +0200
Re: On absurdity of collections 7.6.1 (11.1/3) "G.B." <bauhaus@notmyhomepage.invalid> - 2021-09-30 20:23 +0200
Re: On absurdity of collections 7.6.1 (11.1/3) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-09-30 20:52 +0200
Re: On absurdity of collections 7.6.1 (11.1/3) "Randy Brukardt" <randy@rrsoftware.com> - 2021-09-30 20:40 -0500
Re: On absurdity of collections 7.6.1 (11.1/3) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-10-01 09:57 +0200
csiph-web