mozilla/rust — Issue #1662: reimplement message sending
Author: nikomatsakis
Created: 2012-01-25 20:13:16+00:00
State: open
Labels: rfc

Currently the performance of message sending is not very good. @pcwalton @brson and I have been discussing a possible design and this is what we have so far. Feedback welcome.

## Basic idea

- Channels become a built-in type (for now) probably called `__chan` with an alias.
- Ports and channels are both, in fact, pointers to a C struct layed out roughly like so:

struct port_chan {
int port_ref_count; // non-atomically maintained
int chan_ref_count; // atomically maintained
spinlock_t lock;
task_t *task;
void *queue_data;
};

- When you copy a channel, you increment the chan_ref_count atomically.
- When you copy a port, you increment the port ref count non-atomically.
- When the port ref count reaches 0, the port is "tombstoned:" the queue data is freed and the hold on the task is released.
- When both port and channel ref reach 0, the port is freed altogether.

## Possible danger:

- The tombstone is not freed until all channels go away. In principle some task could accumulate a lot of channels and never release them? But it's not a very big allocation so perhaps this is not a big concern.

## Possible future optimizations:

- If the atomic ref counts become a perf. hit, then we can represent channels as an additional per-task structure which is non-atomically ref counted but holds a single atomic ref on the `port_chan`. Downside is that we have to have a `send_glue` (or perhaps implement using shape code *shudder*) because we need to inc. atomic ref count only on sends (and dec on free).
- For now, we allocate a fixed-size queue. We can optimize this to have it start small---perhaps use tagged pointers so that the first send doesn't need to allocate at all. This is based on an intution that many port/chan pairs are used exactly once.
- The "L4" optimization: make a send_recv primitive and try to convert RPC-like calls into a context switch into the recipient task. This deserves its own bug and its own discussion.

## Next steps

- Look into what other similar open source projects do.
- Then, assuming no great alternatives present themselves, implement.