[Tkinter-discuss] mtTkinter version 0.2 uploaded

Guilherme Polo ggpolo at gmail.com
Thu Nov 27 15:43:45 CET 2008


On Thu, Nov 27, 2008 at 12:15 PM, Allen Taylor
<Allen.Taylor at mdacorporation.com> wrote:
> Hi Guilherme,
> I will cobble something together in the next few days and post it.
> If you are working on redoing _tkinter, would you consider taking the same
> approach to thread-safety as I did in mtTkinter? If so, perhaps mtTkinter
> could be obsoleted.

I'm not approaching the problem exactly as you did, but I'm trying to
make it thread safe.

I have considered three distinct cases:

1) Python has thread support, Tcl doesn't

  Tcl_GetCurrentThread() will always return 0 here, so checking this
against the initial value returned by Tcl_GetCurrentThread() and
stored when the intrepreter was created will not always indicate that
the thread that is about to do something is indeed the one that
created Tcl. Here I check if PyThread_get_thread_ident() is the same
as the one that created the tcl interpreter, if it not, it just
re-schedules the call.

2) Python has no thread support, Tcl does

  I didn't recompile Python without thread support to test this case
but basically it would be the inverse of the previous case. The only
difference is internal to Tcl.

3) Both have thread support

   This case is basically the combination of the previous two.


The differences from this thing that I'm calling "plumage" and
_tkinter in regard to threads are:
  i) It works (at least in the tests I've done) in all the three cases
where tkinter will always fail in the first case;
 ii) It doesn't use a busy loop in order to get the thread responsible
for the interpreter, instead it will re-schedule the call as much as
needed (tests needed for possible problems here)

> Allen
>



-- 
-- Guilherme H. Polo Goncalves


More information about the Tkinter-discuss mailing list