[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtkmm
Subject:    Re: [gtkmm] Handles and such.
From:       Paul Barton-Davis <pbd () Op ! Net>
Date:       1999-05-19 0:59:45
[Download RAW message or body]

>No, there isn't a big problem with GUI code.  It already is sitting
>arround waiting while the user interacts or the window refreshs.  
>However, for use in non-GUI code I could see the signals ending
>up causing slowness or other problems.  It is kind of beyond the
>scope of Gtk-- though, so I won't worry about it til we actually
>have a multithread Gtk-- program.

hey! whose "we" ? *i* already have a multithreaded (5-6 threads) Gtk--
program.

i'm still trying to carefully think through Karl's description of
potential problems (obvious, with hindsight) in the signalling
system. its not an easy thing to think about. i suspect that my
program doesn't suffer from these problems, because (1) signal senders
are mostly persistent for the life of the program and (2) no thread
ever deletes another thread's objects (this was a design goal to allow
the use of pthread_malloc(), although I don't use it at this time).

but as i say, its hard to think about it, so i'm still trying.

--p

[prev in list] [next in list] [prev in thread] [next in thread]