Hi Jecel,

----- Original Message -----
From: "Jecel Assumpcao Jr" <jecel at merlintec.com>

> This is from memory, so don't trust me on this. Acknowledges were
> expressions starting with a double up arrow, right?

yes, according to his book.

> In a system like QNX you have SYNC SEND, SYNC RECEIVE and REPLY. The
> client software just SENDs, while the server is in a loop explicitly
> RECEIVEing and REPLYing. As soon as it REPLYs (sorry about the bad
> English) it allows the client to continue execution while in parallel
> it can continue doing things until the next RECEIVE.

I see.  The trick for me, in understanding why an Ack is useful, seems to be
to think of the server as an active object which is doing more than just
handling requests from clients.  I can imagine that scenario.

> In CST a client can block or not (SYNC SEND, ASYNC SEND) but the server
> does not explicitly receive the messages. Instead, every time it
> finishes executing the previous method (return or REPLY) it implicitly
> waits for the next message. But what if you have things to do after
> calculating the final result (so the client could continue if it was
> blocked on a SYNC SEND)? In that case you use an ACKNOWLEDGE in the
> middle of the method instead of REPLY in the final statement in order
> to return the value.

I see.  In the recently posted Async goodie, that I posted, I changed the
behavior of an asynchronous send to return the future to the sender, instead
of returning the receiver.  This future will allow the client to block on
#value, as well as queuing itself to the client's secretary.  I don't have a
mechanism like the Acknowledge feature because of a very simple assumption.
I assume that methods are going to be short and sweet.  If during the
execution of a method, the server sees that there is another task that he
can do, he should asend a message to himself to do so.  This may increase
the granularity of the implicit atomic locking that occurs by routing
message sends through the secretary.  Additionally, the extra work may be
something that the server wants done synchronously with the originally
requested task.

It is a balance between the locking granularity and the readability of the
code.  An attempt was made to hide the async mechanism, but now I think I
come full circle to what others have expressed:  you had better know that
you are doing that.  Much like the proposed lightweight Module annotations,
I decided to provide an optional mechanism of asynchronous message sending.
This framework does not have atomic objects, thus one can still step on
state, by sending normal messages from multiple threads.  The other issue
was the change in contract for the sender.  When sending asynchronously, the
sender must receive one of (receiver, asend trampoline, future).  The future
seems to be the best choice, so that the client can interact with that
instance of sending.

So I am in a bit of a quandry as to how far to take this, notably CBoxes.
The change in contract is interesting and debatable, especially if the
client who creates the asend sending context (the Trampoline) passes it as a
normal object to another client  (replacing Transcript with the Trampoline).
Finally, the granularity of locking directly affects the responsiveness of
multiple, interacting activities.

Perhaps the right use of this is between Components or Spaces.   Note that
the expanded method to create an asend trampoline is
#asendOnReturn:ifError:, so you can specify blocks to execute when an asend
resolves with a value.

> If it was not like this, then it was something equally interesting ;-)

Well, we are over the waterfall and paddling furiously to shore.  :)  I
guess the next question would be whether it makes sense to implement the
CBox!

- Rob

> -- Jecel
>
>