[erlang-questions] monitor/2

[Tony Rogvall]

On 16 mar 2014, at 22:29, Anthony Ramine <n.oxyde@REDACTED> wrote:

> This sounds like a good idea but with many edge cases.
> 
> For starters, there lack a demonitor call with flush option set in the timeout clause.
> 
Thanks. Missed that one.

> Then, from what I understand reading your snippet of code, I gather that the message is only sent once, right?
> 
Well, then plan is/was that UP/DOWN messages are sent as long as the name monitor is till running.

> What happens if I call monitor after the name was registered and wait for ‘UP’? Or will it wait for the process to die and the name to be freed to send a ‘DOWN’? In my opinion, this behaves in manner too different from process monitors to reuse the same function.
> 
To get this to work (the way I want) one message must be sent when the monitor(name, x) is created
to reflect the status of the name registration, DOWN or  UP. The demonitor flush will then remove all
messages matching the Ref. So for "multi shot" version the a demonitor flush is needed in both cases
since a DOWN message may have been sent if the name was not registered at the creation of the monitor.

wait_for_user_p(N) ->
	Timeout = N*100,
	Ref = erlang:monitor(name, user),
	recieve
		{'UP', Ref, name, Pid, user} ->
			link(Pid),
			erlang:demonitor(Ref, [flush]),
			{ok, Pid}
	after
		Timeout ->
			erlang:demonitor(Ref, [flush]),	
			{error, nouser}
	end	.

And as you pointed out a "single shot" version could be simpler to understand and 
be more like the normal monitor. 'whereis' must then be called after the monitor
has been started. The monitor will only send registration changes in this case.

wait_for_user_p(N) ->
	Ref = erlang:monitor(name, user),
	case whereis(user) of
		Pid when is_pid(Pid) ->
			erlang:demonitor(Ref, [flush]),
			link(Pid),
			{ok, Pid};
		_ ->
			Timeout = N*100,
			recieve
				{'UP', Ref, name, Pid, user} ->
				link(Pid),
				{ok, Pid}
			after
				Timeout ->
				erlang:demonitor(Ref, [flush]),	
				{error, nouser}
		end
	end.

I think that name monitors are not really like process or port monitors, where the death of
a process or port naturally removes the monitor since there is nothing to monitor.
The name however will of course continue to exist for ever. I do think 
that the "single shot" version could be acceptable since it solves the problem.

/Tony


> -- 
> Anthony Ramine
> 
> Le 16 mars 2014 à 21:26, Tony Rogvall <tony@REDACTED> a écrit :
> 
>> 
>> On 16 mar 2014, at 00:21, Tony Rogvall <tony@REDACTED> wrote:
>> 
>>> I would like to see (and have been for a long time :):
>>> 
>>> monitor(name, abc) -> reference()
>>> 
>>> and then be able get notifications when the name abc is registered and unregistered.
>>> 
>>> Then notifications could be something like:
>>> 
>>> {'UP',Ref, name, Pid, abc }
>>> {'UP',Ref, name, Port, abc }
>>> {'DOWN', Ref, name, Pid, abc}
>>> {'DOWN', Ref, name, Port, abc}
>>> 
>> 
>> A comment on my own suggestion:
>> 
>> The following (ugly) code in user_sup.erl:
>> 
>> wait_for_user_p(0) ->
>>    {error, nouser};
>> wait_for_user_p(N) ->
>>    case whereis(user) of
>> 	Pid when is_pid(Pid) ->
>> 	    link(Pid),
>> 	    {ok, Pid};
>> 	_ ->
>> 	    receive after 100 -> ok end,
>> 	    wait_for_user_p(N-1)
>>    end.
>> 
>> Could then be replace with:
>> 
>> wait_for_user_p(N) ->
>> 	Timeout = N*100,
>> 	Ref = erlang:monitor(name, user),
>> 	recieve
>> 		{'UP', Ref, name, Pid, user} ->
>> 			link(Pid),
>> 			{ok, Pid}
>> 	after
>> 		Timeout ->
>> 			{error, nouser}
>> 	end	.
>> 
>> 
>>> /Tony
>>> 
>>> 
>>> On 14 mar 2014, at 23:50, Loïc Hoguin <essen@REDACTED> wrote:
>>> 
>>>> Hello,
>>>> 
>>>> I want to discuss monitor/2.
>>>> 
>>>> It's been there for a while, and it's always taking 'process' as first argument. Any plans to add anything else? And if nothing is foreseen before the end of times, any plans to add a monitor/1 instead?
>>>> 
>>>> Thanks.
>>>> 
>>>> -- 
>>>> Loïc Hoguin
>>>> http://ninenines.eu
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>> 
>>> "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>> 
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
> 

"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140317/c45c5e22/attachment.htm>