| Title | Reserve/commit protocol does not cope with exceptions |
| Status | open |
| Priority | optional |
| Assigned user | Gareth Rees |
| Organization | Ravenbrook |
| Description | What happens if there's an exception between mps_reserve and mps_commit (for example, a stack overflow)? The client program might catch the exception further down the stack, and keep going. That would mean that the next call to mps_reserve on the same allocation point would go wrong. In particular, if using the function version of mps_reserve, it hits the assertion: AVER(mps_ap->init == mps_ap->alloc); |
| Analysis | We could make the reserve operation do: ap->alloc = ap->init + size instead of (as at present): ap->alloc = ap->alloc + size Then at least reserve would be idempotent. (But we would have to remove the assertion, thus losing some checking.) An alternative approach is to provide an interface for "resetting" an allocation point (by setting ap->alloc = ap->init) and then we can tell the client to call this from their exception handler. We could also do with test cases that try to do strange things with the reserve/commit protocol, for example creating a large number of allocation points, reserving objects on them in a random order, and then committing them in a different random order. |
| How found | inspection |
| Evidence | None as yet. |
| Created by | Gareth Rees |
| Created on | 2013-11-04 14:48:56 |
| Last modified by | Gareth Rees |
| Last modified on | 2014-10-24 12:47:33 |
| History | 2013-11-04 GDR Created based on discussion with DL and RB. 2014-10-24 GDR Downgraded to optional as it's not affecting anyone. |