[erlang-questions] Scoped group leaders

[Robert Virding]

It's not that bad, the only memory allocated is for the group leader process.

----- "Eric Merritt" <ericbmerritt@REDACTED> wrote:

> I am talking about the situation where no process that where once
> part
> of the group exist any longer. When a group has no processes, the
> group no longer exists, however the memory alloced by this will
> continue to exist, thats the problem.
> 
> On Tue, Jul 5, 2011 at 6:04 PM, Robert Virding
> <robert.virding@REDACTED> wrote:
> > Conceptually a process is always the member of a group so the very
> idea of removing a group leader from a process does not make sense.
> All you can do is assign it another group leader.
> >
> > Robert
> >
> > ----- "Eric Merritt" <ericbmerritt@REDACTED> wrote:
> >
> >> I wouldn't expect in in the prototype. I am more thinking of the
> end
> >> result.
> >>
> >> On Tue, Jul 5, 2011 at 10:31 AM, Yurii Rashkovskii
> <yrashk@REDACTED>
> >> wrote:
> >> > Right now there is no way to remove a group leader from process,
> >> but
> >> > it is not inherently impossible to do so, just was out of scope
> of
> >> > this prototype.
> >> >
> >> > On Tue, Jul 5, 2011 at 8:05 AM, Eric Merritt
> >> <ericbmerritt@REDACTED> wrote:
> >> >> I understand and that makes sense, but it does raise a
> potential
> >> >> problem. That is group leaders are created but never destroyed.
> In
> >> the
> >> >> case of the process itself, this is probably ok. The developer
> >> will
> >> >> have to create some mechanism to know when his group leader is
> no
> >> >> longer useful and have it die on its own. However, I didn't see
> >> any
> >> >> mechanisms to unregister group leaders and reclaim the memory
> >> alloced
> >> >> when they are created. That could be me missing something when
> I
> >> was
> >> >> looking at the code, if so then the point is moot, however if
> not
> >> >> that's something that would probably need to be added to make
> this
> >> >> workable. Of course, that still leaves the problem that if a
> group
> >> >> leader dies unexpectedly, or the user mis-codes his application
> >> and
> >> >> forgets to unregister a group leader when it dies, then he has
> a
> >> >> memory leak. You could say that its a users problem and go from
> >> there,
> >> >> but leaving around unreferenced memory just doesn't smell
> right.
> >> (I
> >> >> know, we do that already with the atom table, but it doesn't
> make
> >> it a
> >> >> good thing)
> >> >>
> >> >> On Mon, Jul 4, 2011 at 6:57 PM, Robert Virding
> >> >> <robert.virding@REDACTED> wrote:
> >> >>> ----- "Eric Merritt" <ericbmerritt@REDACTED> wrote:
> >> >>>
> >> >>>> >
> >> >>>> >
> >> >>>> >> Just out of curiosity does a group leader go away when a
> >> group
> >> >>>> dies?
> >> >>>> >
> >> >>>> > Define group death?
> >> >>>> >
> >> >>>>
> >> >>>> When when all processes in a group have terminated, either
> >> normally
> >> >>>> or
> >> >>>> abnormally.
> >> >>>
> >> >>> Today there is nothing in the system which keeps track of the
> >> processes in a group, process groups don't really exist at all. A
> >> "process group" is those processes which have the same group
> leader.
> >> The group leader has no information about which processes have it
> as
> >> group leader. You can make any process a group leader by setting it
> as
> >> group leader.
> >> >>>
> >> >>> Process groups were explicitly added in such a way as NOT to
> >> impose any structure or hierarchy on processes, process space is
> >> flat.
> >> >>>
> >> >>> Robert
> >> >>>
> >> >>
> >> >
> >