Re: Message queues: TIsland vs TIslandController

This is exactly how it works. The island's event queue is a priority 
queue of messages, sorted by time. TIsland methods like #decode:, 
#scheduleMessage:at:, and #advanceTo: can be used to deliver, schedule 
and execute messages up to any time you'd like to. TIslandController and 
friends use this API to "run" the islands by controlling the flow of 
time coming from the router. It is utterly trivial to write a little 
loop that executes all outstanding messages right away but it is also 
utterly pointless  A more realistic thing to try is to run the 
messages based on the local wall clock which TLocalController does.

And just in case you are wondering why this is being factored into the 
various controllers instead of subclassing TIsland - that's because you 
can't snapshot an image segment for replication with all that crap in it 

Cheers,
   - Andreas

Matthew Fulmer wrote:
> On Tue, Jul 08, 2008 at 06:07:10PM -0700, Andreas Raab wrote:
>> Matthew Fulmer wrote:
>>> I don't understand the relationship between TIsland and
>>> TIslandController. Why do both of them have a message queue and
>>> a current time?
>> Actually TIslandController doesn't have a current time. However, it 
>> utilizes its own event loop because there is so much concurrent 
>> interaction going on that it's easier to synchronize it by scheduling it 
>> via its own event loop. That event queue is entirely unrelated to the 
>> islands' queue.
>>
>>> It seems to me that TIsland should have no notion of time, and
>>> just be a message queue, while TIslandController knows about
>>> time and releases messages to the TIsland when it needs them
>> That's exactly what the controller does. The TIsland needs its own 
>> notion of time though since it must be able to schedule internal future 
>> messages.
>>
>> Cheers,
>>    - Andreas
> 
> It seems to me that time should be seperated from the event
> queue. I think it should work like this:
> 
> A TIsland has a priority queue of messages to be executed. The
> Island can be started, stopped, or stepped at any time. A
> TIslandController would use this low-level mechanism to
> implement time, stepping the island until the time of the next
> message is greater than the goal time. Messages, both internal
> and external, would pass through the controller to recieve their
> priority
> 
> This would also allow other messaging policies to be plugged in,
> such as a simple fifo executer, that allowed all messages to run
> as fast as possible in the case that no inter-island
> synchronization is needed.
>