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 <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
>>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
::
Re: [DNG] Doing away with multi-thr…
