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
