Updated the MapReduce protocol so that it's correct more often. It's
still not perfect, but the bugs repro less often now.
Also found a race condition in channel sending. The problem is that
send and receive both need to refer to the _unread field in
circular_buffer. For now I just grabbed the port lock to send. We can
probably get around this by using atomics instead.
We're trying to get closer to doing correct move semantics for channel
operations. This involves a lot of cleanup (such as removing the
unused sched parameter from rust_vec constructor) and making
circular_buffer kernel_owned.
Added tagging for memory allocations. This means we give a string tag
to everything we allocate. If we leak something and TRACK_ALLOCATIONS
is enabled, then it's much easier now to tell exactly what is leaking.
This is just until unwinding works. Adds a flag to the runtime to turn
the memory leak checks on task destruction into warnings instead of fatal
errors. I am so sorry.
Issue #428
When the root task fails the process fails. Failures on other tasks propagate
up the task tree. Failures on non-root tasks without parents just
(theoretically) unwind and disappear.
The first is that the memory_region destructor would complain there is
still an outstanding allocation. This is because circular_buffer from
rust_chan wasn't refing its task, so the task was being destructed too
soon.
The second was where the program could deadlock while joining a
task. The target task would die in the time between checking whether
the task should block and then actually blocking. The fix is to use
the target task's lock.
Ports and channels have been moved to the kernel pool, since they've
been known to outlive their associated task. This probably isn't the
right thing to do, the life cycle needs fixed instead.
Some refactorying in memory_region.cpp. Added a helper function to
increment and decrement the allocation counter. This makes it easier
to switch between atomic and non-atomic increments. Using atomic
increments for now, although this still does not fix the problem.
The duplication of upcalls is due to the fact that the runtime is
shared between stage0/rustc and stage1/rustc. Once snapshots are
updated, they should be de-duplicated.
The callback happens when a task moves from the "blocked" state to the
"running" state. The callback is also inherited by child tasks. There
is currently only a native API.
This code hasn't been heavily exercised yet.
If the channel is associated with a port then the destructor will assert.
Additionally, destruction of the object is not always appropriate. This brings
the deref() method into sync with the behavior of generated rust code which
only invokes destroy() once the reference count goes to 0.
The macro with the extra dtor parameter is intended for structures like
rust_chan which may not necessarily delete themselves when the ref count
becomes 0. This functionality will be used in an upcoming changeset.
