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 > _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng