Fixed some fairly major bugs and uploaded to http://tkinter.unpythonic.net/wiki/mtTkinter. Allen
On Wed, Oct 29, 2008 at 1:45 PM, Allen Taylor <Allen.Taylor@mdacorporation.com> wrote:
Fixed some fairly major bugs and uploaded to http://tkinter.unpythonic.net/wiki/mtTkinter. Allen
Hi Allen, Is there any possibility of including samples that demonstrate bad behaviour against current _tkinter but works when using mtTkinter ? I'm working on redoing _tkinter, as time allows (and have restarted doing it twice I think), and finally it seems to getting to some point now. I've created some tests for when tcl/tk are compiled with thread support and when they are not, but the tests are not compatible with _tkinter at all for now and that is why I'm asking for samples from your side. It is possible that you have more cases of when it fails then I do, so if you can provide any it would help this new _tkinter and other people would understand more clearly what mtTkinter solves. Regards, -- -- Guilherme H. Polo Goncalves
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. Allen
"Guilherme Polo" <ggpolo@gmail.com> 2008-11-26 18:48 >>> On Wed, Oct 29, 2008 at 1:45 PM, Allen Taylor <Allen.Taylor@mdacorporation.com> wrote: Fixed some fairly major bugs and uploaded to http://tkinter.unpythonic.net/wiki/mtTkinter. Allen
Hi Allen, Is there any possibility of including samples that demonstrate bad behaviour against current _tkinter but works when using mtTkinter ? I'm working on redoing _tkinter, as time allows (and have restarted doing it twice I think), and finally it seems to getting to some point now. I've created some tests for when tcl/tk are compiled with thread support and when they are not, but the tests are not compatible with _tkinter at all for now and that is why I'm asking for samples from your side. It is possible that you have more cases of when it fails then I do, so if you can provide any it would help this new _tkinter and other people would understand more clearly what mtTkinter solves. Regards, -- -- Guilherme H. Polo Goncalves
On Thu, Nov 27, 2008 at 12:15 PM, Allen Taylor <Allen.Taylor@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
"Guilherme Polo" <ggpolo@gmail.com> 2008-11-27 09:43 >>> 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) By "re-schedule", do you mean to use a queuing techique, or do you plan on indefinitely polling? Allen
On Thu, Nov 27, 2008 at 12:55 PM, Allen Taylor <Allen.Taylor@mdacorporation.com> wrote:
"Guilherme Polo" <ggpolo@gmail.com> 2008-11-27 09:43 >>> 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) By "re-schedule", do you mean to use a queuing techique, or do you plan on indefinitely polling?
On Tcl side a queue is always used, but on Python side you don't have these nice functions for enqueueing events for specific threads so I'm hoping that eventually (by using Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS or similar code) the thread I want will be used.
Allen
-- -- Guilherme H. Polo Goncalves
On Thu, Nov 27, 2008 at 1:23 PM, Guilherme Polo <ggpolo@gmail.com> wrote:
On Thu, Nov 27, 2008 at 12:55 PM, Allen Taylor <Allen.Taylor@mdacorporation.com> wrote:
"Guilherme Polo" <ggpolo@gmail.com> 2008-11-27 09:43 >>> 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) By "re-schedule", do you mean to use a queuing techique, or do you plan on indefinitely polling?
On Tcl side a queue is always used, but on Python side you don't have these nice functions for enqueueing events for specific threads so I'm hoping that eventually (by using Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS or similar code) the thread I want will be used.
I was able to work on it more than I expected and now you can find the first version of it at http://code.google.com/p/plumage/ There are probably many problems with it as it is right now, and there are no examples there either, and no documentation.. well, good luck in trying to use it =) I have done some tests here but I need to rearrange them before commiting, but they will appear there tomorrow or even today. Regarding the documentation, well, it is almost an excuse but didn't have the time to document it yet :P I'm also planning to port the Tkinter python code to work with plumage. Finally, anyone attempting to compile will almost surely have to hand edit the Makefile (and of course you need the python-dev package for your distribution -- not even mentioning Windows here, but if you want to adapt the Makefile and something more to compile under Windows.. -- or a python compiled from source, you know). Have fun, -- -- Guilherme H. Polo Goncalves
On Sat, Nov 29, 2008 at 2:54 PM, Guilherme Polo <ggpolo@gmail.com> wrote:
On Thu, Nov 27, 2008 at 1:23 PM, Guilherme Polo <ggpolo@gmail.com> wrote:
On Thu, Nov 27, 2008 at 12:55 PM, Allen Taylor <Allen.Taylor@mdacorporation.com> wrote:
"Guilherme Polo" <ggpolo@gmail.com> 2008-11-27 09:43 >>> 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) By "re-schedule", do you mean to use a queuing techique, or do you plan on indefinitely polling?
On Tcl side a queue is always used, but on Python side you don't have these nice functions for enqueueing events for specific threads so I'm hoping that eventually (by using Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS or similar code) the thread I want will be used.
I was able to work on it more than I expected and now you can find the first version of it at http://code.google.com/p/plumage/
There are probably many problems with it as it is right now, and there are no examples there either, and no documentation.. well, good luck in trying to use it =) I have done some tests here but I need to rearrange them before commiting, but they will appear there tomorrow or even today. Regarding the documentation, well, it is almost an excuse but didn't have the time to document it yet :P
I'm also planning to port the Tkinter python code to work with plumage.
Finally, anyone attempting to compile will almost surely have to hand edit the Makefile (and of course you need the python-dev package for your distribution -- not even mentioning Windows here, but if you want to adapt the Makefile and something more to compile under Windows.. -- or a python compiled from source, you know).
It now has some short examples on how to use it as raw as it gets and I also ported Tkinter.py to work with it (IDLE is known to not work with it right now).
Have fun,
-- -- Guilherme H. Polo Goncalves
participants (2)
-
Allen Taylor -
Guilherme Polo