:: Re: [DNG] Doing away with multi-thr…
トップ ページ
このメッセージを削除
このメッセージに返信
著者: tilt!
日付:  
To: dng
題目: Re: [DNG] Doing away with multi-threading in my project (netman)
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
>