LablGTK2: problem w/ GMain.Io

LablGTK2: problem w/ GMain.Io

[Matt Gushee]

Hello, all--

I suppose this question is best suited for the LablGTK list. But since I 
have been trying to subscribe to that list for several days, and haven't 
gotten any response yet ...

I have a GUI application (the Bantam file manager) that I originally 
wrote in LablTk, and have just ported to LablGTK2. I wrote most of the 
code on a Slackware 10.1 box using GODI with OCaml 3.08.4 and LablGTK2 
20040716. The GTK2 version is 2.6.1. After implementing all current 
features in GTK and eliminating most of the known serious bugs, I built 
and installed the package on my other Linux box, which runs Arch Linux 
0.7.1, with Ocaml-3.09.2, GTK2-2.8.17, and LablGTK2-2.6.0.

Since I found startup to be a bit slow with GTK, I implemented a 'daemon 
mode' for the application. When you start it in daemon mode, the GUI is 
initialized, but remains hidden until it receives a '%show' command via 
a named pipe. Also, when you 'quit' the application via a keystroke 
command or the window manager, it actually only hides the main window. 
To actually quit the application in daemon mode, you send a '%quit' 
command via the above-mentioned pipe.

Here's the problem: on the development (Slackware) box, I had the app 
running in both normal (GUI shows on startup & is destroyed by quitting) 
and daemon modes with no apparent problems. On the second box, normal 
mode works fine; the app will also run in daemon mode. But when I 
attempt to send a command to the app in daemon mode, I get the following 
error message:

  ** (bantam.bin:13244): CRITICAL **: GIOChannel watch: callback raised \
     an exception

The relevant code is as follows. Have I done something obviously wrong? 
If not, can anyone suggest how to debug this? TIA for any assistance.


   method daemon_setup () =
      is_daemon <- true;
      msg_pipe <- Filename.concat Util.temp_user_dir "message.pipe";
      if not (Sys.file_exists Util.temp_user_dir) then
         Unix.mkdir Util.temp_user_dir 0o755
      else if Sys.file_exists msg_pipe then
         Unix.unlink msg_pipe;
      Unix.mkfifo msg_pipe 0o600;
      msg_fd <-
         Unix.openfile msg_pipe [Unix.O_RDONLY; Unix.O_NONBLOCK] 0o600;
      let chan = GMain.Io.channel_of_descr msg_fd in
      let watcher _ =
         let cmdbuf = Buffer.create 4
         and temp = " " in
         let rec read_input ready =
            let nchars = GMain.Io.read chan ~buf:temp ~pos:0 ~len:1 in
            if nchars = 0 then ()
            else
               match temp with
               | "%" -> read_input true
               | "\n" -> read_input false
               | s when ready -> (Buffer.add_string cmdbuf s; read_input 
true)
               | _ -> read_input false
         and do_command cmdstring =
            match cmdstring with
            | "show" -> self#show ()
            | "hide" -> self#hide ()
            | "quit" -> self#really_quit ()
            | "hup" -> self#hup ()
            | cs -> self#warn ("Unknown command: " ^ cs) in
         read_input false;
         do_command (Buffer.contents cmdbuf);
         true in
      ignore (GMain.Io.add_watch ~cond:[`IN] ~callback:watcher chan)



-- 
Matt Gushee
The Reluctant Geek: http://matt.gushee.net/rg/

Re: [Caml-list] LablGTK2: problem w/ GMain.Io

[Olivier Andrieu]

Hi,

> I have a GUI application (the Bantam file manager) that I originally
> wrote in LablTk, and have just ported to LablGTK2. I wrote most of the
> code on a Slackware 10.1 box using GODI with OCaml 3.08.4 and LablGTK2
> 20040716. The GTK2 version is 2.6.1. After implementing all current
> features in GTK and eliminating most of the known serious bugs, I built
> and installed the package on my other Linux box, which runs Arch Linux
> 0.7.1, with Ocaml-3.09.2, GTK2-2.8.17, and LablGTK2-2.6.0.
>
> Since I found startup to be a bit slow with GTK, I implemented a 'daemon
> mode' for the application. When you start it in daemon mode, the GUI is
> initialized, but remains hidden until it receives a '%show' command via
> a named pipe. Also, when you 'quit' the application via a keystroke
> command or the window manager, it actually only hides the main window.
> To actually quit the application in daemon mode, you send a '%quit'
> command via the above-mentioned pipe.
>
> Here's the problem: on the development (Slackware) box, I had the app
> running in both normal (GUI shows on startup & is destroyed by quitting)
> and daemon modes with no apparent problems. On the second box, normal
> mode works fine; the app will also run in daemon mode. But when I
> attempt to send a command to the app in daemon mode, I get the following
> error message:
>
>   ** (bantam.bin:13244): CRITICAL **: GIOChannel watch: callback raised \
>      an exception

That's because your callback raised an exception (!). LablGTK traps
uncaught exceptions from callbacks instead of re-raising them and exiting
the main  loop. For signals, there is a user-overridable handler that
simply prints the exception name to stderr ; for other types of callbacks
(IO watches, timeouts, etc.) you simply get this error message.

In your code you should wrap your "watcher" function in a try...with block
and print the exception using Printexc.to_string to see what's going
wrong.

-- 
  Olivier

Re: [Caml-list] LablGTK2: problem w/ GMain.Io

[Matt Gushee]

Olivier Andrieu wrote:

 >> and daemon modes with no apparent problems. On the second box, normal
 >> mode works fine; the app will also run in daemon mode. But when I
 >> attempt to send a command to the app in daemon mode, I get the following
 >> error message:
 >>
 >>   ** (bantam.bin:13244): CRITICAL **: GIOChannel watch: callback 
raised \
 >>      an exception
 >
 > That's because your callback raised an exception (!). LablGTK traps
 > uncaught exceptions from callbacks instead of re-raising them and exiting
 > the main  loop. For signals, there is a user-overridable handler that
 > simply prints the exception name to stderr ; for other types of callbacks
 > (IO watches, timeouts, etc.) you simply get this error message.
 >
 > In your code you should wrap your "watcher" function in a try...with 
block
 > and print the exception using Printexc.to_string to see what's going
 > wrong.

Thanks for the tip ... I suppose I should have thought of it myself.

Anyway, I seem to have solved the problem ... I had:

   msg_fd <-
     Unix.openfile msg_pipe [Unix.O_RDONLY; Unix.O_NONBLOCK] 0o600;

Apparently the file descriptor should *not* be opened in non-blocking 
mode (is that really so obvious that it doesn't need to be documented 
anywhere??). But I'm still puzzled, because the behavior was very 
inconsistent: it worked on one box but not another--though perhaps the 
difference in GTK versions would account for that. What was really 
strange, though, was that if I attempted to display the GUI in the 
normal way, i.e. with the command

   $ bantam -s

'bantam' being a shell script which, given the '-s' option, does the 
following:

   echo '%show' > ${TMPDIR}/bantam-${USER}/message.pipe

(which in my case resolves to

   echo '%show' > /tmp/bantam-matt/message.pipe

) --this caused the I/O error. Yet, if invoked the same 'echo' command 
directly in an interactive shell (in this case, bash running in an 
rxvt), it never caused the error. Why on earth would that be, I wonder?

-- 
Matt Gushee
The Reluctant Geek: http://matt.gushee.net/rg/

Re: [Caml-list] LablGTK2: problem w/ GMain.Io

[Matthew Hannigan]

On Thu, May 11, 2006 at 04:05:19PM -0600, Matt Gushee wrote:
> 
>   echo '%show' > /tmp/bantam-matt/message.pipe
> 
> ) --this caused the I/O error. Yet, if invoked the same 'echo' command 
> directly in an interactive shell (in this case, bash running in an 
> rxvt), it never caused the error. Why on earth would that be, I wonder?

At a guess because stdin is a tty, then output might be line buffered
(regardless of destination?)