asynchronous comunication, wxPython and threads.

[Zunbeltz Izaola]

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