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
> >