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 <slitt@???> 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 <edbarx@???> 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 <slitt@???> wrote:
>> > On Wed, 2 Sep 2015 11:47:34 +0100
>> > Edward Bartolo <edbarx@???> 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@???
>> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>> >
>
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>