This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bash misbehavior


On Tue, Sep 28, 2004 at 07:49:31PM -0400, Pierre A. Humblet wrote:
>Here is my current thinking.  When a process sets its own pgid, and it
>changes, open the pgid process and save the inheritable handle on the
>cygheap (together with its pgid), close the original handle (if any),
>and also set the pgid on the pinfo.  When a parent sets the pgid of the
>child, and it changes, open the pgid process and dup it, non heritable,
>in the child's space, on the child pinfo.
>
>When a child forks or execs, check if there is a pgid handle in the
>pinfo and if there is one on the cygheap, and if the cygheap pgid
>matches the pinfo pgid.  Close and dup handles as needed until the
>right handle is inheritable on the cygheap and there is none on the
>pinfo.
>
>If the parent sets the pgid twice in a row, without the child cleaning
>up, we end up with an unreferenced non-heritable handle in the child.
>That's not a tragedy.  There are also unlikely cases where the parent
>and the child set the child's pgid to different values at the same
>time...
>
>I wish this could be simplified.

Can you still open a handle on a process that has exited?  I can't
remember but I think you probably can as long as there is a handle open
to it somewhere.  So, your scheme would probably work.  I just hate the
complication, too.  That's why I've never implemented anything like this.
It's been a long time since I've thought about this problem, though.  It's
nice to have commiseration.  :-)

I was idly thinking that whenever a process group leader exits and
notices that there are still unexited processes sitting around in the
process group it could run a dummy process with a handle to the process.
Thiw process would somehow noticed when the last referencing process
died and would then die itself.

You could run the cygwin dll itself to cause this to happen so you
wouldn't need another .exe sitting around.  I think you can use rundll32
to do this but I've never tried it.

The tricky part is having the dummy process notice when all of the other
users of the process group have gone away.  I guess you could use the
tty technique of opening a dummy 'process group' event in all of the
process group holders.  When you can no longer open this event, all
users of the process group have gone away.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]