On Tue, 21 Jun 2005 15:30:41 +0100, Toby Dickenson wrote: > On Tuesday 21 June 2005 14:22, Zunbeltz Izaola wrote: > > > I guess you are accessing the socket from both your GUI thread and > communications thread. Dont do that. An action in the GUI thread should > signal the communictions thread, then the communictions thread talks to the > socket. >
I see ..., Could be the problem that the socket is created in the GUI thread? the function that end the theraded function (abort()) set want_abort = True This make the Measurement() function to return. The Measurement() funtion is called by startmeasurement() which is the threaded funciton. After aborting i execute a function that FinalizeMeasuremnt() that does comunication to some adjustament in the machine. Maybe i have to move this portion to the threaded funtion. > > Using non-blocking sockets in the GUI thread may cause the opposite problem > to > the one that led you to use threads in the first place: a blocking operation > in the GUI may freeze the communications. Maybe that isnt a problem for you. > If it is, I suggest sticking to two threads. > Yes, i think i have to stick to two threads. > > If you are talking to only one device, then using blocking sockets is a good > approach. However Ive never written an application like this that didnt need > to support a second (or third) machine sooner or later, and three > communictions threads is starting to get ugly. A framework like Twisted will > let you handle many machines in the one thread, but it still makes sense to > keep a second one for the GUI. I didn't get this. What do you do when you have more tham one device; use thread or use Twisted? Did you use it whit wxPython. I think thereis some problems of compatibility. Thank you very much. Zunbeltz -- http://mail.python.org/mailman/listinfo/python-list
