Differentiate between EVENT_SPAM* and wakeup (XCC)
authorBarret Rhoden <brho@cs.berkeley.edu>
Tue, 4 Aug 2015 21:14:23 +0000 (17:14 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Mon, 28 Sep 2015 19:14:00 +0000 (15:14 -0400)
commit3e51313c09e4cd50c9dbd45dd07941f37804f71d
treee155c0f5258adaf1d909b2623a3cb3e84ed2ff21
parentf9d5a74f64a3160ba5afebd0913753a277f3a486
Differentiate between EVENT_SPAM* and wakeup (XCC)

Spamming is getting the message to some vcore that is guaranteed to
eventually receive the message (in a VCPD mbox).  Previously, this also
implied waking up the process.

This is slightly problematic, since spamming is tied to the VCPD mboxes.
If you want to wake up, you had to involve a VCPD mbox.  It ties the
wakeup to a *specific type* of mbox - in this case, the VCPD is a UCQ.
In the future, I'd like other mbox types, such as the "bitmap" type used
by the __ros_scp_simple_evq.

This commit splits the wakeup functionality into a new flag:
EVENT_WAKEUP.  Conceptually, it might be easier to follow the code this
way too.  Want a wakeup (from WAITING)?  Use EVENT_WAKEUP.

Almost all use cases that use some form of SPAM (public message or
indir) will also want a wakeup.  Maybe someone wants to be sure to hear
about something (spammed message), but don't care enough to wake up -
sort of a "if I happen to be running, I need to know FOO".

It's more plausible that an MCP could want a wakeup without the spam.
You could have a process-wide ev_q that was polled in a 2LS sched_entry.
There's no need for a spammed INDIR in this case.

Reinstall your kernel headers.
kern/include/ros/event.h
kern/src/event.c
tests/alarm.c
user/benchutil/alarm.c
user/parlib/signal.c
user/parlib/uthread.c
user/pthread/pthread.c