Hi Edward,
AFAIK Status must be a pointer, because fpwaitpid will write
information into that status.
Also, you should check the return value of fpwaitpid():
0 : nothing has happened
-1: an error occurred, check fgGetErrno
other: the pid of a child where something happened
so like (pseudocode):
cint rv;
pcint Status;
while true
rv := waitpid(-1, Status, WNOHANG);
if rv=-1
{* an error occured, report fpGetErrno *}
return;
else if rv<>0
{* rv is the pid that was reaped,
you could report rv and Status now *}
return;
else
{* nothing has happened, resume waiting *}
continue;
end;
If that doesn't help, check that this way of handling
children does not conflict with some option you have
set for the child TProcess.
Best regards,
T.
On 09/03/2015 08:38 AM, Edward Bartolo wrote:
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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
