Re: About-me-password backend

["Johannes H. Jensen" <joh deworks net>]

Hi Darren, thank you for your reply!

Using signal() makes a lot more sense than what I'm (and the previous  
developer was) doing! I will look at it as soon as I get back from my  
vacation. I'll bug you (and the list) if I run into any more  
problems, if that's ok? :)

Btw, I have long wanted to learn more about the underlying UNIX  
programming environment, and I guess this is my opportunity :) In  
fact, I recently ordered a book on the subject - Advanced Programming  
in the UNIX Environment - which I hope will provide me with all the  
information I need.

Best regards,

Johannes H. Jensen
deworks


On 11. apr. 2006, at 10:42:48, Darren Kenny wrote:

> Hi Johannes,
>
> The most correct way to handle the status of a child process is to  
> catch the unix signal 18 - SIGCHLD - this should be fired by the OS  
> (assuming unix based) should the fork/execed process exit.
>
> So you need to set up a signal handler for SIGCHLD, before you  
> enter the processing loop, and have this signal handler store the  
> pid of the passwd process so that later you can check if this is  
> the one that exited.
>
> Meanwhile, a loop with a  read on an file descriptor (e.g. waiting  
> for the "Password: " string from passwd) will be interrupted due to  
> the SIGCHLD and return -1, and errno will be set to EINTR - if you  
> check for these conditions and then call the child_exited call then  
> you should know if passwd exited.
>
> For example:
>
>    signal( SIGCHLD, reapChildProcess );
>    while ( ! done ) {
>        if (read(...) < 0 ) {
>            if ( errno == EINTR && child_exitied( passwd_pid) ==  
> TRUE ) {
>                done = TRUE; /* or whatever you want to do to exit  
> gracefully */
>                continue; /* or break if you want to force exit of  
> the loop */
>            }
>        }
>        /* normal processing */
>    }
>
> (BTW, I'm assuming you don't have multiple processes forked, if you  
> do you probably need to store the last N processed exited for check  
> to work).
>
> There should be loads of examples of this type of thing on the net...
>
> Darren.
>
> Johannes H. Jensen wrote:
> > Dear almighty GNOME hackers, I'm in need of some pointers!
> >
> > I'm currently hacking on the about-me password dialog (see  
> > #321567), which is spawning /usr/bin/passwd to authenticate and  
> > change the password. In the new dialog, I'm dividing the process  
> > in two, so that the user has to authenticate with his current  
> > password first (which spawns passwd to verify). If passwd doesn't  
> > complain and prompts for the new password, he can enter his new  
> > password, retype it and hit "Change password". When he hits the  
> > button, some time has elapsed since he first authenticated (and  
> > thus passwd was spawned).
> >
> > Now my question is, what happens if passwd suddenly dies during  
> > that time period? Is it likely it will? If so, what's the best way  
> > to periodically(?) ensure that the process is running? Check every  
> > n seconds with waitpid() in the main loop? As far as I can see,  
> > this is how it's done in the current version - wait_child() is  
> > called every 4 seconds to check what the backend is doing...
> >
> > Any pointers greatly appreciated :)
> >
> > Btw, a more detailed mockup of the program/process flow can be  
> > found at http://joh.deworks.net/password-dialog/ 
> > GnomeAboutMePassword.html
> >
> > Best regards,
> >
> > Johannes H. Jensen
> > deworks
> >
> >
> > _______________________________________________
> > desktop-devel-list mailing list
> > desktop-devel-list gnome org
> > http://mail.gnome.org/mailman/listinfo/desktop-devel-list