Mail Archives: cygwin/2008/01/27/08:39:28
------=_NextPart_000_0091_01C860E9.DD4A0000
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
On 26 January 2008 02:27, Jim Kleckner wrote:
>> Thanks for providing a testcase. Should be fixed in CVS:
>> <http://www.cygwin.com/ml/cygwin-patches/2007-q3/msg00013.html>
>
> I have a python application that works fine
> on Linux and Mac but fails with Cygwin.
>
> I tried using snapshot:
> cygwin-inst-20080122.tar.bz2
> but it still fails. (In addition, stdout appears to not get flushed in
> that snapshot).
That's presumably a snapshot of 1.7.0, which is pretty work-in-progressy at
the moment?
> Is it the case that the patch to the header
> file requires the recompilation of applications
> and libraries that use threading to make them work?
>
> See these messages for context:
> http://cygwin.com/ml/cygwin/2007-09/msg00120.html
> http://cygwin.com/ml/cygwin/2006-12/msg00451.html
> http://cygwin.com/ml/cygwin/2006-05/msg00125.html
The two testcases I found in those threads (attached) both WJFFM under
cygwin 1.5.25-7 but fail under 1.5.23-2. If you can reproduce that and your
program still fails, it's probably a different issue.
cheers,
DaveK
--
Can't think of a witty .sigline today....
------=_NextPart_000_0091_01C860E9.DD4A0000
Content-Type: text/plain;
name="foo2.py"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="foo2.py"
#!python
# From http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/82965
"""
This recipe describes how to handle asynchronous I/O in an environment where
you are running Tkinter as the graphical user interface. Tkinter is safe
to use as long as all the graphics commands are handled in a single thread.
Since it is more efficient to make I/O channels to block and wait for somet=
hing
to happen rather than poll at regular intervals, we want I/O to be handled
in separate threads. These can communicate in a threasafe way with the main,
GUI-oriented process through one or several queues. In this solution the GUI
still has to make a poll at a reasonable interval, to check if there is
something in the queue that needs processing. Other solutions are possible,
but they add a lot of complexity to the application.
Created by Jacob Hall?n, AB Strakt, Sweden. 2001-10-17
"""
import Tkinter
import time
import threading
import random
import Queue
class GuiPart:
def __init__(self, master, queue, endCommand):
self.queue =3D queue
# Set up the GUI
console =3D Tkinter.Button(master, text=3D'Done', command=3DendComm=
and)
console.pack()
# Add more GUI stuff here
def processIncoming(self):
"""
Handle all the messages currently in the queue (if any).
"""
while self.queue.qsize():
try:
msg =3D self.queue.get(0)
# Check contents of message and do what it says
# As a test, we simply print it
print msg
except Queue.Empty:
pass
print "done processIncoming"
class ThreadedClient:
"""
Launch the main part of the GUI and the worker thread. periodicCall and
endApplication could reside in the GUI part, but putting them here
means that you have all the thread controls in a single place.
"""
def __init__(self, master):
"""
Start the GUI and the asynchronous threads. We are in the main
(original) thread of the application, which will later be used by
the GUI. We spawn a new thread for the worker.
"""
print "__init__"
self.master =3D master
# Create the queue
print "Queue"
self.queue =3D Queue.Queue()
# Set up the GUI part
print "GuiPart"
self.gui =3D GuiPart(master, self.queue, self.endApplication)
# Set up the thread to do asynchronous I/O
# More can be made if necessary
self.running =3D 1
print "running"
self.thread1 =3D threading.Thread(target=3Dself.workerThread1)
self.thread1.start()
# Start the periodic call in the GUI to check if the queue contains
# anything
print "peridicCall"
self.periodicCall()
def periodicCall(self):
"""
Check every 100 ms if there is something new in the queue.
"""
print "processIncoming"
self.gui.processIncoming()
if not self.running:
# This is the brutal stop of the system. You may want to do
# some cleanup before actually shutting it down.
print "exiting"
import sys
sys.exit(1)
print "self.master.after"
self.master.after(100, self.periodicCall)
print "done periodicCall"
def workerThread1(self):
"""
This is where we handle the asynchronous I/O. For example, it may be
a 'select()'.
One important thing to remember is that the thread has to yield
control.
"""
print "workerThread1"
while self.running:
# To simulate asynchronous I/O, we create a random number at
# random intervals. Replace the following 2 lines with the real
# thing.
time.sleep(rand.random() * 0.3)
msg =3D rand.random()
self.queue.put(msg)
def endApplication(self):
print "endApplication"
self.running =3D 0
rand =3D random.Random()
root =3D Tkinter.Tk()
client =3D ThreadedClient(root)
root.mainloop()
------=_NextPart_000_0091_01C860E9.DD4A0000
Content-Type: text/plain;
name="foo.py"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="foo.py"
#!python
# Demonstrate python/Tkinter threading bug
import sys, types, os, threading
import Tkinter as TK
from time import sleep
class App:
def __init__(self, root):
self.root =3D root
self.update_loop()
# Start a second thread, to do whatever...
self.thread =3D threading.Thread(target=3Dself.second_thread)
self.thread.start()
def update_loop(self):
print >>sys.stderr, "*** update_loop"
self.root.after(400, self.update_loop)
def second_thread(self):
sleep(100)
if __name__ =3D=3D "__main__":
root =3D TK.Tk()
app =3D App(root)
root.mainloop();
------=_NextPart_000_0091_01C860E9.DD4A0000
Content-Type: text/plain; charset=us-ascii
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
------=_NextPart_000_0091_01C860E9.DD4A0000--
- Raw text -