The logic im mp_barrier_wait is wrong. decrement_counter returns
the value of the counter __before__ it is decremented. Before
the fix, the counter decremented until it reached 0 and then the
next arriving thread would get stuck in decrement_counter. Also,
interrupts were not reenabled in all cases.
If mp_process_enable is interrupted after pthread_create, but
before its exit code is examined, the cleanup code may be run
even when pthread_create did not fail, so we need to disable
interrupts in this region.
If a thread is killed while it holds a spinlock, the lock will
never be released, leading to deadlocks. Hence we have to clean
up spinlocks in ECL_WITH_SPINLOCK_END. In mp_process_enable,
other cleanup (deallocating the environment, unlisting the
process) has to performed too.
This is important to prevent race conditions. If interrupts are
left disabled, the environment may be wrongly write protected by
an interrupting thread and completely harmless writes in the
environment can lead to segmentation faults.
If a process, that has already unwound its whole frame stack
(after ECL_CATCH_ALL_END in thread_entry_point) is interrupted by
a call to mp_exit_process, ECL will crash with a segmentation
fault. We thus need to aquire the start_stop_spinlock before we
unwind the frame stack.
If a thread is interrupted while interrupts are disabled by C,
then the signal is queued and the environment is write protected
by mprotect. If another thread then calls queue_signal, it will
try to write in the protected environment, leading to a
segmentation fault. Since mprotect can only protect whole memory
pages, we need to allocate the pending interrupts and the signal
queue in a separate struct.
It didn't wake up all processes to check the condition what caused n+1 lag in
condition check for signal-process (when called with n>1). Fixes#421. No
regression test, because this is already tested in sem-signal-* tests (they were
failing).
bytecompiled functions may not have a name (i.e lambda assigned to
smothing). Recognize that fact, so when we read back such functions
from file we can call bc-compile on them. Fixes#313.
When mp_process_interrupt and thread_cleanup are called at the same
time, it is possible that the thread-local environment is deallocated
while ecl_interrupt_process tries to use it. This two methods thus
need to be protected with a lock.
si_set_finalizer is CL-world function and returns 0 values. That means
in particular, that env->nvalues is changed.
In this situation, when new binding was introduced, we could lose our
nvalues, what lead to invalid multiple-value-bind (next commit will
contain a regression test).
We use unprotected version. If interrupts cause problems with it, we
may need to wrap it in disable_interrupts. Threading code uses
ecl_set_finalizer_unprotected without such wrapping though, so I
believe that should be safe.
Fixes#233.
These two function are the same.
Here is my understanding: FEprogram_error_noreturn was introduced with
the noreturn function attribute in commit 7d9fb8bb because
FEprogram_error did not have this attribute. However, FEprogram_error
got the noreturn function attribute in commit 790d466c. Now there is
no reason to have both of these.
This removes FEprogram_error_noreturn and changes all calls to it
with calls to FEprogram_error instead.
This is for signalling an error about binding a constant variable.
This makes the error messages originally in commits 745686, c9e732
and 4e3283 more precise.
PROGV was allowed to bind constants in the C-compiler and the bytecode
compiler and interpreter, but the behavior would differ between them:
> (defun foo ()
(flet ((memq (item list) (member item list :test #'eq)))
(progv (list :test) (list :test-not)
(memq 'bar '(bar baz quux)))))
FOO
> (foo)
(BAZ QUUX)
> (compile 'foo)
FOO
> (foo)
(BAR BAZ QUUX)
CLHS says the behavior is undefined when attempting to bind or assign
constant variables (CLHS 3.1.2.1.1.3 and the entry for defconstant).
The C-compiler and bytecode compiler and interpreter give errors when
attempting to bind or assign constant variables in lambda expressions,
LET, SETQ and various other binding/assignment forms. So the behavior
above in PROGV is inconsistent.
Now give an error when attempting to bind a constant variable in PROGV
in the C-compiler and the bytecode compiler and interpreter.
