On Thu, 3 Sep 2015 07:38:13 +0100
Edward Bartolo <edb...@gmail.com> wrote:
I'd figure out how to stop those zombies from happening in the first
place. It's pretty hard to create a zombie: I think you have to
doublefork and then terminate. In that case, if you're using a good
init system, I believe you can send PID1 a SIGCHLD, and PID1 will reap
zombies. I know that's how suckless-init works. I suggest you download
Suckless-Init and look at its source: It's only 83 non-blank lines.
But again, I think the question "how do I reap zombies" is a little
like "how do I sweep up broken glass", when you're dropping and
breaking 3 glasses every day. The better question is "why am I dropping
these glasses?"
SteveT
> I am trying to reap zombies. The "while(fpwaitpid" pascal code is
> freezing my application.
>
> *********************************************************************************
> procedure handle_sigchld(sig: longint; info: psiginfo; context:
> psigcontext); cdecl;
> var
> Status: cint;
> a_pid: pid_t;
> begin
> Status := 0;
> a_pid := -1;
>
> // This is freezing my application
> while (fpwaitpid(a_pid, Status, WNOHANG) > 0) do
> begin
> backend_lives := backend_lives + 1;
> showmessage('hi strunz!!!');
> end;
> end;
>
>
> var sa: sigactionrec;
>
> initialization
> sa.sa_handler := @handle_sigchld;
> fpsigemptyset(&sa.sa_mask);
>
> sa.sa_flags := (SA_RESTART or SA_NOCLDSTOP);
> if (fpsigaction(SIGCHLD, @sa, nil) = -1) then
> begin
> // do nothing
> end;
> ******************************************************
>
> Any ideas?
>
>
> Edward
>
>
>
> On 02/09/2015, Steve Litt <sl...@troubleshooters.com> wrote:
> > Personally, I'd go waaaaay out of my way never to multithread unless
> > there were a huge reason to do so. Your app does such a small, quick
> > job that there's no reason.
> >
> > You mentioned the front and back end communicating with each other,
> > and everyone mentioned fifos. I agree. And if there's a reason for
> > one program to tell the other that info's ready for it, that's what
> > SIGUSR1 and SIGUSR2 are for. Or at least what *I* use them for.
> >
> > SteveT
> >
> > Steve Litt
> > August 2015 featured book: Troubleshooting: Just the Facts
> > http://www.troubleshooters.com/tjust
> >
> >
> > On Wed, 2 Sep 2015 19:45:08 +0100
> > Edward Bartolo <edb...@gmail.com> wrote:
> >
> >> What about multithreading? Should I do away with it and let the
> >> frontend monitor for zombies to call waitpid?
> >>
> >> Edward
> >>
> >> On 02/09/2015, Steve Litt <sl...@troubleshooters.com> wrote:
> >> > On Wed, 2 Sep 2015 11:47:34 +0100
> >> > Edward Bartolo <edb...@gmail.com> wrote:
> >> >
> >> >> Hi all,
> >> >>
> >> >> I think, I found an alternative to multithreading in netman.
> >> >> This is using interprocess communication, although what I have
> >> >> in mind may not be proper interprocess communication.
> >> >>
> >> >> The idea is this: the backend would be converted into some sort
> >> >> of a daemon exporting one function and importing another one.
> >> >> The frontend would use the exported function from the backend
> >> >> to send it commands. The backend would do the same thing with
> >> >> the exported function from the frontend:
> >> >>
> >> >> Visually, this is as follows:
> >> >>
> >> >> Frontend -------------->> Backend
> >> >> Frontend <<-------------- Backend
> >> >>
> >> >> In my humble opinion, this may help getting rid of having to use
> >> >> multithreading to avoid temporary frontend deadlocks. It also
> >> >> solves the issue with zombies being created, and would permit me
> >> >> create a responsive application but using the KISS principle.
> >> >
> >> > I like it. A lot!
> >> >
> >> > IMHO the front end should do nothing but display ESSIDs with
> >> > strength and encryption, letting you click on the one you want or
> >> > right click and say "turn off" to turn it off.
> >> >
> >> > If you've already dealt with that ESSID, the back end has the
> >> > password and uses it to join that ESSID. If the back end hasn't
> >> > dealt with it, it sends the front end a message saying "get me
> >> > the password", the front end queries the user for the password,
> >> > and the front end sends it back to the back end. Assuming one
> >> > user, this doesn't even have to be stateful, but if it has to be
> >> > stateful, there are a million ways to do it.
> >> >
> >> > I like it!
> >> >
> >> > SteveT
> >> >
> >> > Steve Litt
> >> > August 2015 featured book: Troubleshooting: Just the Facts
> >> > http://www.troubleshooters.com/tjust
> >> > _______________________________________________
> >> > Dng mailing list
> >> > Dng@lists.dyne.org
> >> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> >> >
> >
> >
> > _______________________________________________
> > Dng mailing list
> > Dng@lists.dyne.org
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> >
SteveT
Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
