Re: [Twisted-Python] Help for Twisted + Thread + Message Queue
![](https://secure.gravatar.com/avatar/3f005f5f4b914c3ddd2f993dae4c9799.jpg?s=120&d=mm&r=g)
Hi... Thanks for reply. I know SSCCE.... But I have not code yet. I'm doing some investigation to understand if it is the right way or if twisted has a better standard flow for a similar problem. I will try to write something.... exarkun@twistedmatrix.com ha scritto:
On 04:57 pm, s.danzi@hawai.it wrote:
Hi!!
I have to write a little python program to manage a serial port radio modem. I have to send some AT commands and read resposes. This is not a problem, twisted examples are enough.
...but I have a situation that makes things complicated:
Anytime the modem can send back to serial port a line starting with "++"... I have to catch it and do some analysis that could take a long time.
How to solve????????????????
Hi Stefano,
Please read http://sscce.org/ and post again with more information.
Thanks, Jean-Paul
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
![](https://secure.gravatar.com/avatar/1846c8040fcf70e9b55bb7bfcdb78bc4.jpg?s=120&d=mm&r=g)
Hi Stefano, It's probably a good idea to avoid thinking in threads until they come up as a potential solution. Some questions: 1) What are the latency requirements? Is it okay for everything else to halt while you do that computation? What are the latency requirements for the computation? Is the data useless if you don't get it in the next n seconds? 2) What kind of machine is it running on? Are multiple cores available, and would it make sense to use them? 3) Do you require a lot of shared state with the process talking to the modem in order to make the long computation? The easiest thing to do is probably deferToThread, but you have to be careful not to touch any state you're not supposed to touch. The second easiest thing is probably Ampoule, a process pool, or maybe just regular AMP, if you only want a regular process. Those would have the benefit that the reading process is never doing anything hard, so latency should stay predictable. hth lvh
![](https://secure.gravatar.com/avatar/3f005f5f4b914c3ddd2f993dae4c9799.jpg?s=120&d=mm&r=g)
Hi Laurens, many thanks for yours considerations. 1) I don't have problems about latency but I can't halt all during the computation. I can defer the computation for minutes if I attach to data the timestamp related to when data arrives. 2) The "monster" machine that have to do all is an embedded pc based on 1000MHz AMD Geode NX1500 3) The long computation need only the data. In extremis I could write data on a file or DB and compute using another program. I bit better explanation of scenario: The radiomodem take "unexpected data" from a network of varius sensors. The sensors could be reachable or not. The only way to know when the sensor is reachable is to wait fo "unexpected data". If I need to send data to a specific sensor I have to do it immediatly after it send me "unexpected data", wait also 1 second could be sufficient to have the sensor no longer reachable. I can't send data to sensor and after do computation because meanwhile could arrive data from another sensor. Mainly it is the reason because I think to defer long computation to another thread..
![](https://secure.gravatar.com/avatar/1846c8040fcf70e9b55bb7bfcdb78bc4.jpg?s=120&d=mm&r=g)
On Fri, Oct 4, 2013 at 10:59 AM, Stefano Danzi <s.danzi@hawai.it> wrote:
Hi Laurens, many thanks for yours considerations.
1) I don't have problems about latency but I can't halt all during the computation.
Why not?
I can defer the computation for minutes if I attach to data the timestamp related to when data arrives.
Sure, gettimeofday is a thing, that shouldn't be a problem.
2) The "monster" machine that have to do all is an embedded pc based on 1000MHz AMD Geode NX1500
Okay, so single core.
3) The long computation need only the data. In extremis I could write data on a file or DB and compute using another program.
I would imagine you do that anyway for persistence reasons with the results :)
I bit better explanation of scenario:
The radiomodem take "unexpected data" from a network of varius sensors. The sensors could be reachable or not. The only way to know when the sensor is reachable is to wait fo "unexpected data". If I need to send data to a specific sensor I have to do it immediatly after it send me "unexpected data", wait also 1 second could be sufficient to have the sensor no longer reachable.
I can't send data to sensor and after do computation because meanwhile
could arrive data from another sensor.
Mainly it is the reason because I think to defer long computation to
another thread..
Okay, so try with threads first, and hope that the scheduler lets your reactor thread work often enough. If that doesn't work, do the computation in a subprocess, and hope that nice works well enough :) lvh
participants (2)
-
Laurens Van Houtven
-
Stefano Danzi