Date: Fri, 26 Apr 1996 15:10:00 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: sef@kithrup.com, hackers@FreeBSD.org Subject: Re: Something fishy with our PT_ATTACH code! Message-ID: <199604262210.PAA28041@phaeton.artisoft.com> In-Reply-To: <229.830534797@time.cdrom.com> from "Jordan K. Hubbard" at Apr 26, 96 09:06:37 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > It doesn't seem that the detached process is suspending itself so much as it > > is simply renotifying the parent that it is still stopped. This could be > > wrong behaviour, however. > > > > To change that, in the PT_DETACH code, a > > > > psignal(p, SIGCONT); > > > > would do the trick. I think ;). > > Well, it seems to me that we should really restore the process's > previous state - what if it was suspended to start with? :-) begin: initial_state attach_1: current_state -> save_state_1 (initial_state) suspend_state -> current_state attach_2: current_state -> save_state_2 (attach_1_suspend) suspend_state -> current_state detach_1: save_state_1 -> current_state (initial_state) detach_2: save_state_2 -> current_state (attach_1_syspend) end: attach_1_suspend You need to modify attack_2's save_state_2 based on entry order when you detach_1. You need an attach list back-pointer. Or you need to imply O_EXCL and prevent reeentrancy. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604262210.PAA28041>