Tomorrow, I will make it a point to push my multithreaded version of
netman for evaluation. You will see multithreading did not add much
complexity with the benefit of better frontend responsiveness and no
zombies lurking around.

On 03/09/2015, Edward Bartolo <edbarx@???> wrote:
> I kept a multithreaded netman version installed on my computer so that
> I would be able to connect to wifi with a couple of button clicks. All
> I can say is, that it doesn't create zombies and it is well behaved.
> What we should do is do away with execl which *replaces* backend
> effectively killing it and letting the new child execute. The backend
> is already using popen to run executables, so we can use that instead
> of the problematic execl. This to make things easier for TThread
> instead of expecting it to behave when we call execl which kills the
> thread controlled by TThread.
>
> I think, TThread may present a simple solution that allows us to keep
> the code effectively as it is without a drastic overhaul.
>
> What I need is to use ps to check for any children owned by netman,
> and the whole application will be almost ready.
>
> ps command: ps xao pid,ppid,comm | grep netman
> Look for any process parented by netman and adjust the frontend
> accordingly and we are almost ready.
>
> Edward.
>
> On 03/09/2015, Steve Litt <slitt@???> wrote:
>> On Thu, 3 Sep 2015 18:24:51 +0100
>> Edward Bartolo <edbarx@???> wrote:
>>
>>> I found that the created zombies are owned by root and the frontend
>>> does not run with root privileges. I think, this may be the reason.
>>>
>>> The reason why zombies are created is that we are effectively
>>> replacing backend by what execl calls. We may be able to solve the
>>> issue by allowing the backend to continue running when execl is used
>>> and at the end call wait() if that is possible.
>>
>> Holy cow! Why does anything require execl()? As this whole escapade
>> goes to show, execl() has complication that is not without cost. I'm
>> also not sure why C is needed.
>>
>> I'm thinking your back end could probably be a simple shellscript that
>> interacts with wpa_supplicant and its config file. I'll admit the
>> documentation for wpa_supplicant is ambiguous, contradictory and
>> pathologically incomplete, but I'm pretty sure nothing about this
>> problem domain requires execl(). Just have the back end running, and
>> have the front end communicate with it in a simple and well documented
>> manner of your design.
>>
>> 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
>>
>