On Feb 25, 2007, at 7:29 AM, Jeffrey Ratcliffe wrote:
> On 25/02/07, muppet <[EMAIL PROTECTED]> 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
_______________________________________________
gtk-perl-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
