<br><br><div class="gmail_quote">2009/3/9 Richard O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
On 10 Mar 2009, at 2:08 am, Hubert Plociniczak wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Message {test, test1, test2} is first in the message. foo is second.<br>
Similarly as in original receive I take the newest message and check if only with this message I can satisfy any of the joins.<br>
If that is not possible, then I go the next message and check if any of the joins can be satisfied using the new message (and all previous ones).<br>
Since {test, test1, test2} already satisfies one of the joins, then I fire it immediately and do not look at what else is in the message<br>
after {test, test1, test2} (though I might obviously look at it in the future, if I have any receive constructs afterwards).<br>
<br>
I hope that helps.<br>
</blockquote>
<br></div>
Actually, it helps to scare me off.<br>
It reminds me too much of XSLT.<br>
For one thing, the current receive construct (conceptually)<br>
always starts its search with the *OLDEST* message, not the<br>
newest one.<br>
<br>
So we have in the mailbox<br>
   oldest = {test,test1,test2}<br>
   newest = foo<br>
and in the matching process, the first thing we hit is<br>
   _X and foo<br>
and _X does match the first message that we should look<br>
at (namely the oldest) and foo does then match the<br>
remaining message.<br>
</blockquote><div><br>Ok, I agree I named newest for the oldest. When explaining I always get the naming the other way around ;)<br>To satisfy the join I am trying to find the smallest, oldest set of messages in the mailbox.<br>
<br>When designing the joins I took the same approach as receive, i.e. it takes the message and consecutively matches it against patterns, step by step.<br>If it doesn't find any pattern that satisfied the message, then it moves to the next message and repeats.<br>
I didn't want to change this logic, because the other way would mean to have a look at *some* (possibly big) snapshot of the mailbox and check if the first patterns is satisfied. If not, then check another one etc.<br>
<br>But then what happens when new messages arrive? There is no way to ensure (without limiting the size of the snapshot) that previous pattern (or in my case join) was not satisfied, as some new message that arrived in the meantime could satisfy it.<br>
<br>This particular case is tricky, so thanks for pointing that out. But I think it still is correct, because in reality, without joins, it is the second case (namely _X) that would get satisfied (not _X and foo) - if you were to hard-code it using for example nested receives.<br>
<br>hubert<br></div></div>