| Allegro CL version 10.1 Unrevised from 10.0 to 10.1. 10.0 version |
This variable determines whether delete uses the in-place style of modification to change a simple vector, or if it makes a copy of the old vector after the matching slots have been compressed out of it. It serves as the default value to a new keyword argument to delete.
To set this variable to nil
causes the
contents of the vector to change as usual, but the size of the
original vector is never modified. Instead, a copy is made and given
the correct new size, and is returned from delete.
To set this variable to true in an SMP Lisp is very dangerous; it could result in the Lisp's heap becoming corrupted if any two threads are working on the same object at the same time. (Though unlikely, this can happen in a non-SMP multiprocessing Lisp as well.) An in-place modification of the size of a vector could remove the protections in code which is unsafe but correct by causing the second thread to see a different size than the underlying storage actually contains. If (setf aref) is used in this manner and stores beyond the current end of the array, codewalkers and especially the garbage-collector could then see an inconsistent heap and the lisp could die with a gc-error. The code could be as innocuous as
(declare (optimize speed)) (dotimes (i (length vec)) (setf (aref vec i) t)))
If, in an SMP Lisp, another thread has called delete and the in-place option is set, then the vector may change out from under this thread's loop, and the (setf aref) clauses may write off the end of the array, causing death.
While heap corruption will not happen when the sequence argument is a list, other unspecified and unexpected behavior can result.
Deleting in place is safe when only one thread traverses a sequence.
This variable is set globally, and is not bound on any threads, but is not declared non-bindable; it may be bound and the value used based on user needs.
The initial value is t
in non-SMP Lisps and
nil
in SMP Lisps.
See cl:delete, cl:delete-if, cl:delete-if-not, cl:delete-duplicates: multiprocessing issues in implementation.htm for details.
Copyright (c) 1998-2022, Franz Inc. Lafayette, CA., USA. All rights reserved.
This page was not revised from the 10.0 page.
Created 2019.8.20.
| Allegro CL version 10.1 Unrevised from 10.0 to 10.1. 10.0 version |