If you make the difference between strong and weak sends at the port level,
then you cannot do both type of sends with the same port. However from my
experience this is something you want to do in real applications. Why do you
want to make that difference at the port level instead of the send operation
level ?
Donatien
>
> The current Fault module is complicated and inadequate for fault
> detection on ports. Here is a proposal to improve that. The
> initial proposal is by Donatien Grolaux, with modifications after
> discussions with Peter Van Roy, Seif Haridi, and Per Brand.
>
> Instead of distinguishing between tempFail and permFail,
> we look at things from the application's point of view.
> There are three possibilities when doing an operation:
> the operation has succeeded, the operation has not yet
> succeeded, and the operation was cancelled.
>
> Instead of a single Port.send operation, there are two,
> Port.send and Port.sendNotify. The latter has an extra
> argument to confirm when the message has been delivered
> to the process on the destination site. The extra argument
> can be bound to true or false or cancel(_). It may remain
> unbound indefinitely.
>
> There are two kinds of ports, strong and weak. A send
> on a strong port is as before: it continues to try to send the
> message indefinitely, even when there are problems. (It
> may silently give up if the distribution subsystem detects a
> permanent failure, but this is invisible from the application
> point of view.) A send on a weak port gives up if the
> message cannot be delivered immediately.
>
> There is a cancel operation that will cause any pending strong
> send operations to give up immediately and cause their
> notification arguments to be set immediately. If the message
> delivery is as yet unsure when the cancel is done, the notification
> is bound to cancel(X), where X may eventually be bound to true
> or false. This is important because more information may come in
> later (e.g., when the network starts working again or a persistent
> site comes back up).
>
> This gives the following API:
>
> {Port.new T ?S ?P} where T is strong, weak, or centralized.
> A centralized port is defined for debugging purposes: it gives
> an error when used remotely. The old NewPort operation
> creates a strong port.
>
> {Port.send P X} performs a send.
> {Port.sendNotify P X ?N} performs a send and does its best
> to bind the notification N eventually.
>
> {Port.cancel P} cancels all pending strong sends and binds their
> notification arguments accordingly.
>
> Note that no exceptions are ever raised in this proposal.
>
> All comments are welcome.
>
> We still need to understand what needs to be done for distributed
> variables. All proposals are welcome for them.
>
> Peter Van Roy
> -
> Please send submissions to hackers@mozart-oz.org
> and administriva mail to hackers-request@mozart-oz.org.
> The Mozart Oz web site is at http://www.mozart-oz.org/.
>
-
Please send submissions to hackers@mozart-oz.org
and administriva mail to hackers-request@mozart-oz.org.
The Mozart Oz web site is at http://www.mozart-oz.org/.