> In the function, shove the serial data into a pipe that the main thread > can read from in a function invoked by a GDK Input call:
Done. Seems to work... I worked on the code and tried to crash it for an hour and a half, to no avail, so I think it's fixed. I guess GDK just cleans itself up before giving control over to my code, so I can make GTK calls without breaking anything. Looks good! Thanks a lot! -Nate > On Thu, 2006-06-15 at 16:28 -0400, [EMAIL PROTECTED] wrote: >> No, it's not in a seperate thread, it's a function that gets called >> asynchronously by the kernel. But that function *does* then make GTK >> calls. Would it be safer to tie my serial port routines to one of those >> GDK IO callbacks, that way I know it's safe to muck around when I get >> called? > > In the function, shove the serial data into a pipe that the main thread > can read from in a function invoked by a GDK Input call: > > http://developer.gnome.org/doc/API/2.0/gdk/gdk-Input.html > > at least, that's what I do. > > > // Wally > >> >> - Nate >> >> > It sounds like lightening the load merely reduces the chance of >> hitting >> > some race condition. You say your app makes heavy use of the serial >> > port. Are you doing this in a separate thread? If so, is that thread >> > also making gtk calls (in addition to the main thread)? >> > >> > >> > // Wally >> > >> > On Thu, 2006-06-15 at 14:41 -0400, [EMAIL PROTECTED] wrote: >> >> I'm writing an application that makes fairly heavy use of the serial >> >> port. >> >> While testing this app, things seem to be running fine, until I >> wiggle >> >> the mouse quickly over a treeview (a list) or over a few checkboxes >> in >> >> the >> >> window. Sometimes I have to wiggle for a minute, sometimes just 5 >> >> seconds >> >> will do, but the app crashes, with either a segfault, or GLib >> reporting >> >> a >> >> corrupted doubly linked list. >> >> >> >> Some thoughts: >> >> 1. Wiggling the mouse anywhere besides over the treeview or the >> >> checkboxes causes no problems. >> >> >> >> 2. Processor usage goes up significantly when wiggling the mouse >> over >> >> the >> >> treeview or the checkboxes. >> >> >> >> 3. The problem can be completely avoided by making the offending >> >> widgets >> >> non-sensitive (dimmed out). >> >> >> >> 4. I'm running on an old computer, a Celeron, at around 400Mhz or so >> :( >> >> >> >> Could number 4 be the culprit? Perhaps wiggling the mouse over some >> >> widgets (and thus causing GTK to redraw them, presumably) slows down >> the >> >> system so much (70% processor usage at the time of death sometimes) >> that >> >> some routines or signals interrupt themselves and do something >> naughty? >> >> >> >> When I modify the program (skipping key routines) to drastically >> lower >> >> the >> >> processor usage, the problem goes away. >> >> >> >> I would like to chalk this up to a weak computer... but it seems >> >> unlikely >> >> to me that GTK simply blows up on old computers (with very busy >> apps). >> >> >> >> For reference: >> >> 400 Mhz Celeron >> >> 128 Megs ram >> >> Debian Linux >> >> GTK 2.6 >> >> >> >> Any advice is appreciated! >> >> >> >> _______________________________________________ >> >> gtk-app-devel-list mailing list >> >> gtk-app-devel-list@gnome.org >> >> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list >> > -- >> > Your eyes are weary from staring at the CRT. You feel sleepy. Notice >> > how restful it is to watch the cursor blink. Close your eyes. The >> > opinions stated above are yours. You cannot imagine why you ever felt >> > otherwise. >> > >> > -- > Your eyes are weary from staring at the CRT. You feel sleepy. Notice > how restful it is to watch the cursor blink. Close your eyes. The > opinions stated above are yours. You cannot imagine why you ever felt > otherwise. > _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
