From: "Jeff Henrikson" <jehenrik at yahoo.com>
To: <lablgtk at kaba.or.jp>
Subject: Thread wedge in lablgtk: happens in linux too
Date: Sat, 30 Jun 2001 02:10:10 -0400
Message-ID: <000b01c1012b$515f34e0$0b01a8c0 at mit.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <000a01c100dd$5c7db840$0b01a8c0 at mit.edu>
Importance: Normal

On the threading bug:

I downloaded and built ocaml on my linux box to see if this bug was reproducible there.  With the default thread configuration, I
didn't seem to be able to Thread.create to do anything except return a handle.  I'm not sure if this is normal.

Passing -with-pthread to configure and rebuilding, I got the identical result as under win98 with one observable exception: "mouse
move" events don't appear to be enough to unwedge.  But "mouse entry" and "mouse click" are.  It has been a long time since I
looked at the X mouse handling documentation, but I seem to recall you have to do something special to get sent mouse motion
events.  I know win32 sends them to all applications.  So this makes sense.

At least we know now nobody needs to go setting up a win98 box to observe this.


Jeff Henrikson

> -----Original Message-----
> From: Jeff Henrikson [mailto:jehenrik@yahoo.com]
> Sent: Friday, June 29, 2001 4:52 PM
> To: lablgtk@kaba.or.jp
> Subject: Thread wedge in lablgtk
>
>
> Okay, so I am still having trouble with multithreading GTK on Windows 98. (Using the bytecode compiler, but I think
> native does the
> same thing.)  Basically, I have a test program that makes a window and draws one of two things in it based on a state
> variable.  I
> set up a thread that infinite loops on:
>
> 	toggle state variable
> 	queue redraw request
> 	sleep 1 sec.
>
> The behavior is that the application wedges sometime after painting itself.  It never unsleeps.  However, if any window messages
> happen to get sent (eg, mousemove, keypresses, etc, the thread gets unwedged provided the 1 second time has in fact expired.
>
> Ways I have experimented:
>
> 1) I put printfs before and after every critical thing to determine that the last code that runs is consistently the last paint
> handler command.  I'll put the code below.
>
> 2) I replaced Thread.sleep with a custom C function that called Win32 Sleep(int msecs).  Same behavior.
>
> My code is a modified version of the test sample drawing.ml.  It is below.
>
>
> Many thanks,
>
> Jeff Henrikson
>
>
> drawing.ml:
>
>
> open GMain;;
> open Thread;;
> open GObj;;
> open GtkBase;;
> open Printf;;
>
> let window = GWindow.window ()
> let area = GMisc.drawing_area ~packing:window#add ()
>
> let w = area#misc#realize (); area#misc#window
> let drawing = new GDraw.drawable w
>
> let rec hun = ref 100
>
>
> let redraw _ =
>   match drawing#size with
>     (w,h) ->
>   drawing#set_foreground `WHITE;
>   drawing#rectangle ~x:0 ~y:0 ~width:w ~height:h ~filled:true();
>   drawing#set_foreground `BLACK;
>   drawing#polygon ~filled:true
>     [ 10,!hun; 35,35; 100,10; 165,35; 190,100;
>       165,165; 100,190; 35,165; 10,100 ];
>   (printf "dequeue size=(%d,%d) " w h; flush stdout; 0 );
>   false
>
> (*external emit_happy : GMisc.drawing_area -> name:string -> unit -> unit
>     = "ml_gtk_signal_emit_none"*)
>
>
> let interactionThread i =
>   while true do
>     hun := - !hun;
>     printf "queue "; flush stdout;
>     GtkBase.Widget.queue_draw (window : GWindow.window :> widget)#as_widget;
>     printf "sleep "; flush stdout;
>     Thread.delay 0.1;
>     (*Sleep.sleep 100;*) (* custom native sleep: same behavior *)
>     printf "unsleep "; flush stdout;
>   done;
>   false
>
> let _ =
>   window#connect#destroy ~callback:Main.quit;
>   area#event#connect#expose ~callback:redraw;
>   window#show ();
>
>   let handle = Thread.create interactionThread 8 in
>
>   Main.main ()
>