GTK C development; question/concern wrt gtk_dialog

Sponsored Content

Top Forums Programming GTK C development; question/concern wrt gtk_dialog_run Post 302564716 by DreamWarrior on Friday 14th of October 2011 12:23:29 PM

10-14-2011

Registered User

Quote:

Originally Posted by Corona688

You're getting confused again. Of course you need to mutex your data, and probably keep it in one thread. Why would a single-threaded anything have IPC in it? It's up to the programmer to decide how they want to use it. Unless it mutexed each and every last memory access, how could anything possibly know which things to protect? Again -- up to the programmer.

There's a simple answer to the problem of you calling things like that deep in event handlers; don't do things like that deep in event handlers... it's an interface, you don't need to bury your whole program in it.

Ugh...I think I'm not communicating my thoughts well enough or our wires are crossed. I'm certainly not confused, though, lol. I'm adept at multi-threaded programming and GUI development (and even widget development) in Xt. So, let me try again.

In Xt, if I created a separate worker thread to, for example, handle socket communication outside of the Xt scheduler, I would not be able to have that thread update any GUI elements (for example call XmListAddItem).

Simple example, an application that collects stats and displays them on a GUI. If the stats collection was performed in a separate thread, I couldn't update the stats on the GUI from within that thread because Xt would crash. Neither it nor the Motif widgets protected their data, so I'd end up corrupting it because both the event loop and stats thread would/could attempt to access the same widgets at the same time, for example a list widget could be exposing itself while the stats thread was calling XmListAddItem.

To rectify this, I'd have the stats collection thread pass, via a mutex protected queue using a pipe attached to an Xt "read-ready" input handle as a "there's data there", a message to the GUI thread, more specifically the input callback on the pipe that would be invoked from the main loop executing in that thread, that there were new stats. Since the GUI's thread, running Xt's main loop, would now render the stats there was no possibility that the main loop could receive an expose event concurrently and mess up the widgets.

Now, I'm asking if GTK would suffer the same "problem" or if it and its widgets have thought out multi-threaded access to them. My guess is, no.

Make sense....?

DreamWarrior

View Public Profile for DreamWarrior

Find all posts by DreamWarrior

LEARN ABOUT OSF1

assert_wait_mesg

assert_wait_mesg(9r)													      assert_wait_mesg(9r)

NAME

       assert_wait_mesg - General: Asserts that the current kernel thread is about to block (sleep)

SYNOPSIS

       void assert_wait_mesg(
	       vm_offset_t event,
	       boolean_t interruptible,
	       char *message );

ARGUMENTS

       Specifies the event associated with the current kernel thread.  Specifies a Boolean value that indicates how the kernel thread is awakened.
       You can pass one of the following values: The current kernel thread is interruptible. This value means that a signal can awaken the current
       kernel  thread.	The current kernel thread is not interruptible. This value means that only the specified event can awaken the current ker-
       nel thread.  Specifies a mnemonic for the type of wait. The ps command uses this mnemonic to print out more  meaningful	messages  about  a
       process.

DESCRIPTION

       The assert_wait_mesgroutine asserts that the current kernel thread is about to block (sleep) until the specified event occurs. This routine
       sets a thread wait bit in the pointer to the thread structure associated with the current kernel thread.  This bit signifies that this ker-
       nel thread is on the appropriate wait hash queue, waiting for a wakeup call.

       To actually block (put to sleep) the current kernel thread, call thread_block.

       To issue a wakeup call on the specified event, call the thread_wakeup_prim or clear_wait routine.

CAUTIONS

       You  must  not call assert_wait_mesg from a device driver's interrupt handler. The reason for this is that at interrupt context there is no
       process to be put to sleep.

RETURN VALUES

       None

SEE ALSO

       Data Structures: thread(9s)

       Routines: clear_wait(9r), current_thread(9r), thread_block(9r)

       Reference Pages Section 1: ps

															      assert_wait_mesg(9r)