Read-write locks are always provided; if no operating system
primitives exist, emulate them using ordinary locks. Also provide a
Windows implementation.
- Spinlocks have been replaced by ordinary locks. Without access to
the underyling scheduler, spinlocks provide no performace benefit
and may even be harmful in case of high contention.
- Synchronization of process creation and exiting has been simplified.
Instead of a spinlock, a barrier and atomic operations we now use
only a single lock protecting the shared process state and a
condition variable for implementing process joins.
- Some locks which were implemented using Lisp objects now directly
use a native mutex.
- Our own mutex implementation has been removed as it is now unused.
The old implementation was not race condition free. If two threads (A
and B) were writing at the same time while one thread (C) was reading,
the following could happen:
1. thread A increases the write pointer (but does not store the
message yet)
2. thread B increases the write pointer, stores the message and
signals thread C
3. thread C tries to read from the location that thread A has not yet
written to
The new implementation is a simple and obvious solution using a common
mutex and two condition variables for reading/writing. We don't bother
with a (complex) interrupt safe implementation.
We already have a race condition between mp:get-lock and
mp:holding-lock-p, there is no point in trying to make sure the lock
is released at all costs during an interrupt.
Changes include:
- consistent naming
- replaced unnecessary use of (sleep) by better synchronization mechanisms
- tests are run with timeouts
- clean up stray threads which would otherwise wait for all eternity
- better error messages in case of test failures
Replace slow homegrown mutex implementation by standard OS functions.
We try our best to be interrupt safe, however a completely safe
implementation is impossible (unless one completely removes the ability
to interrupt a thread waiting on a mutex). There is always a window
after the OS specific function has returned, but before we can set
the owner, in which interrupts will see an inconsistent state of the
mutex with regards to owner and count.
Condition variables are now based on OS functions as well. Timed
waiting on condition variables has also been implemented.
On Unix, pathnames are converted into the default encoding specified
by ext:*default-external-format* and back. On Windows, the operating
system already gives us utf16 encoded pathnames, so we use those.
ecl_namestring with ECL_NAMESTRING_FORCE_BASE_STRING encodes with the
specified encoding. Decoding is handled individually in the filesystem
functions.
Includes a minor refactor of list_directory, changing the
PARSE_DIRECTORY_ENTRY macro into an inline function.
Closes#609, #549.
This commit complements the previous one by ensuring that concatenated files are
read in order (after processing previous files) and that we don't check whether
packages are created before we process all files.
This function can be found in lisp code (it is generated by the reader
from backquotes), thus it must be declared in external.h so that the C
compiler can pick it up when we compile the generated C file.
Fixes#648.
The type propagation is invoked with a function compiler-pass/propagate-types
before the compiler-pass2. Previously the type propagation was invoked in
ctop-write.
- separate passes
The separation is not fine-grained but is a good starting point for further
cleanup. This is a preliminary requirement for multiple backends.
- use uninternet symbol in the package definition
- remove "execute" permission from all files
- remove a few unused functions
- rearrange loaded files
- less verbose compiler
Don't print "End of pass 1." message. This doesn't provide any valuable
information to the programmer.
We have already registered a finalizer for the external process object
which calls external-process-wait. This in turn calls si::waitpid
which closes the handle once the process has exited.
Otherwise it can happen that a user-defined finalizer for some object
A storing a builtin object B registers another finalizer for A making
B reachable again while B has already been finalized.
We can't impose an ordering for user-defined finalizers in general
since these may include cyclic references. Therefore it is the duty of
the user to write the finalizers in a consistent way which is
independent of the order in which the finalizers are called. This
doesn't work for builtin objects since the user can't influence
the finalizers in this case.
We also fix a bug which lead to the removal of the standard finalizer
if a user-defined finalizer was registered and then removed.
Co-authored-by: Daniel Kochmański <daniel@turtleware.eu>
