Differences

This shows you the differences between two versions of the page.

--- at:tutorial:distribution [2009/01/29 15:10] – revision elisag
+++ at:tutorial:distribution [2009/01/29 15:21] – elisag
@@ Line 235: / Line 235: @@
 ===== Taking offline remote objects =====
-AmbientTalk distributed memory management scheme has been based on reference listing and network objects. Similar to these techniques, remote far references are implemented by means of a proxy at client-side, which encapsulates a wire representation of the exported object and whose methods are stubs that transform local message sends into distributed message sends. Messages sent to the server include method invocation information, as well as the wire representation of the receiver. Each actor maintains an export object table which maps wire representations onto local references to exported objects. This table is used by the interpreter to resolve remote far references into local object references. Objects in the export table are considered as root objects for the local garbage collector. When an object is removed from the export table, it is no longer accessible remotely and, importantly, it no longer belongs to the set of root objects and as such, it becomes subject to garbage collection once it is no longer locally referenced.
+AmbientTalk distributed memory management scheme has been based on [[http://en.wikipedia.org/wiki/Reference_counting#Variants_of_reference_counting|reference listing]] and network objects. Similar to these techniques, remote far references are implemented by means of a proxy at client-side, which encapsulates a wire representation of the exported object and whose methods are stubs that transform local message sends into distributed message sends. Messages sent to the server include method invocation information, as well as the wire representation of the receiver. Each actor maintains an export object table which maps wire representations onto local references to exported objects. This table is used by the interpreter to resolve remote far references into local object references. Objects in the export table are considered as root objects for the [[http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)|local garbage collector]]. When an object is removed from the export table, it is no longer accessible remotely and, importantly, it no longer belongs to the set of root objects and as such, it becomes subject to garbage collection once it is no longer locally referenced.
-As previously explained, in order to deal with volatile connections, remote far references tolerate network disconnections by default.  To enforce this, objects pointed by remote far references are not automatically taken offline when all their remote far references become disconnected, as traditionally happens in the above mentioned techniques. Rather, the object is kept in the export table since disconnected remote far references remain valid and still refer to the server object while disconnected. This implies a remote object is never reclaimed. AmbientTalk provides the takeOffline: primitive that takes a remote object offline, enabling the object to be eventually locally garbage collection.
+As previously explained, in order to deal with volatile connections, remote far references tolerate network disconnections by default.  To enforce this, objects pointed by remote far references are not automatically taken offline when all their remote far references become disconnected, as traditionally happens in the above mentioned techniques. Rather, the object is kept in the export table since disconnected remote far references remain valid and still refer to the server object while disconnected. This implies a remote object is never reclaimed. AmbientTalk provides the ''takeOffline:'' primitive that takes a remote object offline, enabling the object to be eventually locally garbage collection.
 <code>
@@ Line 246: / Line 246: @@
 <note>
-Leased object references make use of the takeOffline: primitive to terminate the access to a remote object once the lease time elapses. Note that the \atkeyword{takeOffline} primitive can be considered the equivalent to the so-called \texttt{delete} operation provided by some sequential languages without built-in local garbage collection.  Rather than using this primitive for garbage collection purposes, regular AmbientTalk developers are encouraged to use the high-level language constructs for leasing explained above which aids them to deal with both transient and permanent disconnections and properly reclaim their remote objects.
+Leased object references make use of the ''takeOffline:'' primitive to terminate the access to a remote object once the lease time elapses. Note that the ''takeOffline'' primitive can be considered the equivalent to the so-called [[http://en.wikipedia.org/wiki/Manual_memory_management|''delete'' operation]] provided by some sequential languages without built-in local garbage collection.  Rather than using this primitive for garbage collection purposes, regular AmbientTalk developers are encouraged to make use of the high-level language constructs for leasing explained in the previous section which aids them to deal with both transient and permanent disconnections and properly reclaim their remote objects.
 </note>
@@ Line 253: / Line 253: @@
 On the client side, taking offline an object results in a permanent disconnection of the remote far references pointing to it. In other words, despite having network connection, unexporting an object renders remote far references permanently disconnected. This implies that client have to deal explicitly with unexported objects.
-Clients can get notified when an object is taken offline by means of ''when:disconnected:'' observers. Disconnected observers get triggered since the taking offline event is considered as a logical disconnection between two devices. However, an object taken offline is removed from the export table and thus, it cannot go online anymore. As a result, the disconnected and reconnected observers will be no longer trigger for that remote far reference.
+Clients can get notified when an object is taken offline by means of ''when:disconnected:'' observers. Disconnected observers get triggered since the taking offline event is considered as a logical disconnection between two devices. However, once an object taken offline is removed from the export table, it cannot go online anymore. As a result, the disconnected and reconnected observers will be no longer trigger for that remote far reference.
 Additionally, AmbientTalk provides dedicated takenOffline observers which get triggered only once when the object is taken offline. They are installed similarly to when:disconnected observers as follows: