Dispcount resource identification during init

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Dispcount resource identification during init

Edmond Begumisa
Hello all,

Any dispcount[1] users out there? Your assistance on two questions would  
be appreciated..

a) During init function of the callback module implementing the dispcount  
behaviour, I would like to know resource number assigned to that process.  
Is this possible?

The reason is: each of my resources (port programs) need to be initialised  
to use separate directories for storage. For example: "priv/rc1/data",  
"priv/rc2/data", etc. If the dispcount sup restarts resource 1 for  
instance, I would like resource 1 to always use "priv/rc1/data". There  
should be no possibility two or more resources ending up being initialised  
to the same dir due to sup restarts.

The identifier doesn't have to be a number. But if the node/machine  
restarts, the same directories should be used.

b) Is this library still active? One feature mentioned on the todo list  
would be nice to have for our purposes (dynamically growing/shrinking the  
number of resources).

Thanks in advance.

- Edmond -

[1] https://github.com/ferd/dispcount

--
Using Opera's mail client: http://www.opera.com/mail/
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Dispcount resource identification during init

Fred Hebert-2
On 07/19, Edmond Begumisa wrote:
>Hello all,
>
>Any dispcount[1] users out there? Your assistance on two questions
>would be appreciated..
>
>a) During init function of the callback module implementing the
>dispcount behaviour, I would like to know resource number assigned to
>that process. Is this possible?
>

Each process registers itself, so you should be able to find that
information from process_info(self()). Otherwise, nothing is passed
explicitly to the callback.

I'm figuring this might be enough to get going.

>b) Is this library still active? One feature mentioned on the todo list
>would be nice to have for our purposes (dynamically growing/shrinking
>the number of resources).
>

It is, for all intents and purposes, a complete library. There has not
been bug reports nor feature requests, so it is stable.

If someone were to report bugs, I would probably try and fix them, but
it's been pretty calm and stable for the last 4 years. I haven't used or
tried to use it (my work has moved to systems with different
requirements) recently, but I'm still fine maintaining it.

If someone has a plan to improve the libs, I'd be fine handing control
over, though.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Dispcount resource identification during init

Edmond Begumisa
In reply to this post by Edmond Begumisa

The following patch appears to do what I want. Perhaps those familiar with discount internals could confirm its correctness or suggest and alternative approach which doesn't require a patch.


dispcount_watcher.erl

         ...
         init(Id,Conf,M,A) ->
    -         case M:init(A) of
    +         case M:init(Id, A) of
         ...

dispcount.erl

         ...
         behaviour_info(callbacks) ->
    -         [{init,1},
    +        [{init,2},
         ...


- Edmond -


----- Original Message -----

To:
"Edmond Begumisa" <[hidden email]>

Sent:
Thu, 19 Jul 2018 07:53:06 +1000
Subject:
Dispcount resource identification during init


Hello all,

Any dispcount[1] users out there? Your assistance on two questions would
be appreciated..

a) During init function of the callback module implementing the dispcount
behaviour, I would like to know resource number assigned to that process.
Is this possible?

The reason is: each of my resources (port programs) need to be initialised
to use separate directories for storage. For example: "priv/rc1/data",
"priv/rc2/data", etc. If the dispcount sup restarts resource 1 for
instance, I would like resource 1 to always use "priv/rc1/data". There
should be no possibility two or more resources ending up being initialised
to the same dir due to sup restarts.

The identifier doesn't have to be a number. But if the node/machine
restarts, the same directories should be used.

b) Is this library still active? One feature mentioned on the todo list
would be nice to have for our purposes (dynamically growing/shrinking the
number of resources).

Thanks in advance.

- Edmond -

[1] https://github.com/ferd/dispcount

--
Using Opera's mail client: http://www.opera.com/mail/

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Dispcount resource identification during init

Edmond Begumisa
In reply to this post by Fred Hebert-2

Oh,

We seem posted at the same time!

Thanks for this. I'll give process_info(self()) a try.

Good work with the library. Regards.

- Edmond -


----- Original Message -----
From:
"Fred Hebert" <[hidden email]>

To:
"Edmond Begumisa" <[hidden email]>
Cc:
<[hidden email]>
Sent:
Wed, 18 Jul 2018 19:17:13 -0400
Subject:
Re: [erlang-questions] Dispcount resource identification during init


On 07/19, Edmond Begumisa wrote:
>Hello all,
>
>Any dispcount[1] users out there? Your assistance on two questions
>would be appreciated..
>
>a) During init function of the callback module implementing the
>dispcount behaviour, I would like to know resource number assigned to
>that process. Is this possible?
>

Each process registers itself, so you should be able to find that
information from process_info(self()). Otherwise, nothing is passed
explicitly to the callback.

I'm figuring this might be enough to get going.

>b) Is this library still active? One feature mentioned on the todo list
>would be nice to have for our purposes (dynamically growing/shrinking
>the number of resources).
>

It is, for all intents and purposes, a complete library. There has not
been bug reports nor feature requests, so it is stable.

If someone were to report bugs, I would probably try and fix them, but
it's been pretty calm and stable for the last 4 years. I haven't used or
tried to use it (my work has moved to systems with different
requirements) recently, but I'm still fine maintaining it.

If someone has a plan to improve the libs, I'd be fine handing control
over, though.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions