Re: Glib::IO->add_watch not uninstalling

[muppet <scott asofyet org>]

On Feb 25, 2007, at 7:29 AM, Jeffrey Ratcliffe wrote:

> On 25/02/07, muppet <scott asofyet org> wrote:
> > The only thing i see is that you handle 'hup' before checking for
> > 'in'.  It *is* possible to get both conditions in the same callback.
> > However, this would only result in losing the last chunk of input,
> > not a hang.
>
> This is exactly what is happening. I got him to run a modified version
> which prints the conditions, and he was getting
>
> [ in hup ]
>
> (as opposed to [ hup ], which I was getting). Of course
>
>  if ($condition eq 'hup') {
>
> is then no longer true. Is
>
>  if ($condition >= 'hup') {
>
> the RIght Way To Do It?

Well, TIMTOWDI, of course. :-)  But, yes, the ">=" operator, which is  
overloaded for Glib::Flags bitsets to mean the same as "&", which is  
"are all of the flags listed on the right hand side set in the left  
hand side?" is how i would write it.

The Glib::Flags operators are explained in the "This Is Now That"  
section of the Glib manpage.

"eq" or "==" is rarely correct for testing Glib::Flag variables.


And, since you can get both conditions in the same callback, you need  
to change the order of handling the conditions in your callback.   
This idiom usually gets me where i want to go:

    if condition contains "in"
        read and handle data

    if condition contains "write"
        write data

    if condition contains "hup"
        close and clean up
        return FALSE to stop watching

    return TRUE to keep watching

Note the lack of "else"s.



--
I hate to break it to you, but magic data pixies don't exist.
  -- Simon Cozens