From cd84edac7b3affa023c0e3588ab36589c683126b Mon Sep 17 00:00:00 2001 From: Hans Bolinder Date: Wed, 7 Jul 2010 10:27:59 +0200 Subject: reference() substituted for ref() in docs --- lib/kernel/doc/src/erl_ddll.xml | 38 +++++++++++++++++++------------------- lib/stdlib/doc/src/dets.xml | 4 ++-- lib/stdlib/doc/src/io_protocol.xml | 2 +- 3 files changed, 22 insertions(+), 22 deletions(-) (limited to 'lib') diff --git a/lib/kernel/doc/src/erl_ddll.xml b/lib/kernel/doc/src/erl_ddll.xml index 4e65bf46f8..9a62b45d63 100644 --- a/lib/kernel/doc/src/erl_ddll.xml +++ b/lib/kernel/doc/src/erl_ddll.xml @@ -177,7 +177,7 @@ demonitor(MonitorRef) -> ok Remove a monitor for a driver - MonitorRef = ref() + MonitorRef = reference()

Removes a driver monitor in much the same way as @@ -185,7 +185,7 @@ monitors. See monitor/2, try_load/3 and try_unload/2 for details about how to create driver monitors.

The function throws a badarg exception if the - parameter is not a ref().

+ parameter is not a reference().

@@ -400,7 +400,7 @@ Item = {Name, When} Name = atom() | string() When = loaded | unloaded | unloaded_only - MonitorRef = ref() + MonitorRef = reference()

This function creates a driver monitor and works in many @@ -449,7 +449,7 @@ eventually lead to one of the following messages being sent:

- {'UP', ref(), driver, Name, loaded} + {'UP', reference(), driver, Name, loaded}

This message is sent, either immediately if the driver is already loaded and no reloading is @@ -459,7 +459,7 @@ expected to know if reloading is demanded prior to creating a monitor for loading.

 - {'UP', ref(), driver, Name, permanent} + {'UP', reference(), driver, Name, permanent}

This message will be sent if reloading was expected, but the (old) driver made itself @@ -467,7 +467,7 @@ sent if the driver was permanent or statically linked in when trying to create the monitor.

 - {'DOWN', ref(), driver, Name, load_cancelled} + {'DOWN', reference(), driver, Name, load_cancelled}

This message will arrive if reloading was underway, but the user having requested @@ -476,7 +476,7 @@ (or unload/1/unload_driver/1) again before it was reloaded.

 - {'DOWN', ref(), driver, Name, {load_failure, Failure}} + {'DOWN', reference(), driver, Name, {load_failure, Failure}}

This message will arrive if reloading was underway but the loading for some reason @@ -500,7 +500,7 @@

A driver monitor for unload will eventually result in one of the following messages being sent:

- {'DOWN', ref(), driver, Name, unloaded} + {'DOWN', reference(), driver, Name, unloaded}

The driver instance monitored is now unloaded. As the unload might have been due to a @@ -508,7 +508,7 @@ again have been loaded when this message arrives.

 - {'UP', ref(), driver, Name, unload_cancelled} + {'UP', reference(), driver, Name, unload_cancelled}

This message will be sent if unloading was expected, but while the driver was waiting for @@ -525,7 +525,7 @@ similar to an unloaded monitor, but does never result in this message.

 - {'UP', ref(), driver, Name, permanent} + {'UP', reference(), driver, Name, permanent}

This message will be sent if unloading was expected, but the driver made itself @@ -539,7 +539,7 @@

A monitor created as unloaded_only behaves exactly as one created as unloaded with the - exception that the {'UP', ref(), driver, Name, unload_cancelled} message will never be + exception that the {'UP', reference(), driver, Name, unload_cancelled} message will never be sent, but the monitor instead persists until the driver really gets unloaded.

 @@ -626,7 +626,7 @@ ReloadOption = pending_driver | pending Status = loaded | already_loaded | PendingStatus PendingStatus = pending_driver | pending_process - Ref = ref() + Ref = reference() ErrorDesc = ErrorAtom | OpaqueError ErrorAtom = linked_in_driver | inconsistent | permanent | not_loaded_by_this_process | not_loaded | pending_reload | pending_process @@ -650,7 +650,7 @@ registered and a corresponding try_unload is expected sometime in the future.

 - {ok, pending_driver}or {ok, pending_driver, ref()} + {ok, pending_driver}or {ok, pending_driver, reference()}

The load request is registered, but the loading is delayed due to the fact that an earlier instance of the @@ -665,7 +665,7 @@ set. In other words, this return value will always need to be handled!

 - {ok, pending_process}or {ok, pending_process, ref()} + {ok, pending_process}or {ok, pending_process, reference()}

The load request is registered, but the loading is delayed due to the fact that an earlier instance of the @@ -683,7 +683,7 @@ about when the driver is actually loaded. This can be achieved by using the {monitor, PendingOption} option.

When monitoring is requested, and a corresponding {ok, pending_driver} or {ok, pending_process} would be - returned, the function will instead return a tuple {ok, PendingStatus, ref()} and the process will, at a later + returned, the function will instead return a tuple {ok, PendingStatus, reference()} and the process will, at a later time when the driver actually gets loaded, get a monitor message. The monitor message one can expect is described in the monitor/2 @@ -760,7 +760,7 @@

A MonitorOption tells try_load/3 to trigger a driver monitor under certain conditions. When the monitor is triggered, the - function will return a three-tuple {ok, PendingStatus, ref()}, where the ref() is + function will return a three-tuple {ok, PendingStatus, reference()}, where the reference() is the monitor ref for the driver monitor.

Only one MonitorOption can be specified and it is either the atom pending, which means @@ -891,7 +891,7 @@ MonitorOption = pending_driver | pending Status = unloaded | PendingStatus PendingStatus = pending_driver | pending_process - Ref = ref() + Ref = reference() ErrorAtom = linked_in_driver | not_loaded | not_loaded_by_this_process | permanent @@ -943,7 +943,7 @@ ports using it and there are no more users requiring it to be loaded.

 - {ok, pending_driver}or {ok, pending_driver, ref()} + {ok, pending_driver}or {ok, pending_driver, reference()}

This return value indicates that this call removed the last user from the @@ -957,7 +957,7 @@ in that case, however transient. Monitors are as always useful to detect when the driver is really unloaded.

 - {ok, pending_process}or {ok, pending_process, ref()} + {ok, pending_process}or {ok, pending_process, reference()}

The unload request is registered, but there are still other users holding diff --git a/lib/stdlib/doc/src/dets.xml b/lib/stdlib/doc/src/dets.xml index 8d1398d3b7..ad100d2cf5 100644 --- a/lib/stdlib/doc/src/dets.xml +++ b/lib/stdlib/doc/src/dets.xml @@ -109,7 +109,7 @@ bool() = true | false file() = string() int() = integer() >= 0 keypos() = integer() >= 1 -name() = atom() | ref() +name() = atom() | reference() no_slots() = integer() >= 0 | default object() = tuple() object_cont() = tuple() @@ -759,7 +759,7 @@ ok Open an existing Dets table. FileName = file() - Reference = ref() + Reference = reference()

Opens an existing table. If the table has not been properly diff --git a/lib/stdlib/doc/src/io_protocol.xml b/lib/stdlib/doc/src/io_protocol.xml index b52e862a5c..a97d996d98 100644 --- a/lib/stdlib/doc/src/io_protocol.xml +++ b/lib/stdlib/doc/src/io_protocol.xml @@ -79,7 +79,7 @@ sends the reply to. io_reply. The io-module in the Erlang standard library simply uses the pid() of the io_server as the ReplyAs datum, but a more complicated client could have several outstanding io-requests to the same server and -would then use i.e. a ref() or something else to differentiate among +would then use i.e. a reference() or something else to differentiate among the incoming io_reply's. The ReplyAs element should be considered opaque by the io_server. Note that the pid() of the server is not explicitly present in the io_reply. The reply can be sent from any -- cgit v1.2.3