To Thread or not to Thread....?

[Werner Thie]

Hi

I see quite a few alleys to go down when stuck with such types of 
problems, but instead of listing and discussing them have a look at a 
quite complete discussion and comparison of the various async 
programming options available at

http://syncless.googlecode.com

Also have a look at the presentation at

http://syncless.googlecode.com/svn/trunk/doc/slides_2010-11-29/pts_coro_2010-11-29.html

If I were in your shoes I would solve the problem in stackless, if 
exchanging the python interpreter is not possible then Twisted would be 
my second choice, having done a lot of work with it (see the NMEA 
classes for serial ports).

I don't know if syncless handles other types of fd's like serial ports, 
I've never played with it. The monkey patching of syncless might pose 
other problems in your case.

HTH, Werner


Am 01.12.2010 14:48, schrieb James Mills:
> Surely I2C is just a serial-like interface
> and one should be able to do async I/O on it ?
>
> The use of threads is not necessary here and the GIL
> doesn't become a problem in async I/O anyway.
>
> I only use threads for operating that might block (not for I/O).
>
> cheers
> James
>
> On Wed, Dec 1, 2010 at 7:24 PM, Antoine Pitrou<solipsis at pitrou.net>  wrote:
>> On Wed, 1 Dec 2010 02:45:50 +0000
>> Jack Keegan<whatsjacksemail at gmail.com>  wrote:
>>
>>> Hi there,
>>>
>>> I'm currently writing an application to control and take measurements during
>>> an experiments. This is to be done on an embedded computer running XPe so I
>>> am happy to have python available, although I am pretty new to it.
>>> The application basically runs as a state machine, which transitions through
>>> it's states based on inputs read in from a set of general purpose
>>> input/output (GPIO) lines. So when a certain line is pulled low/high, do
>>> something and move to another state. All good so far and since I get through
>>> main loop pretty quickly, I can just do a read of the GPIO lines on each
>>> pass through the loop and respond accordingly.
>>
>>> However, in one of the states I have to start reading in, and storing frames
>>> from a camera. In another, I have to start reading accelerometer data from
>>> an I2C bus (which operates at 400kHz). I haven't implemented either yet but
>>> I would imagine that, in the case of the camera data, reading a frame would
>>> take a large amount of time as compared to other operations. Therefore, if I
>>> just tried to read one (or one set of) frames on each pass through the loop
>>> then I would hold up the rest of the application. Conversely, as the I2C bus
>>> will need to be read at such a high rate, I may not be able to get the
>>> required data rate I need even without the camera data. This naturally leads
>>> me to think I need to use threads.
>>> As I am no expert in either I2C, cameras, python or threading I thought I
>>> would chance asking for some advice on the subject. Do you think I need
>>> threads here or would I be better off using some other method. I was
>>> previously toying with the idea of using generators to create weightless
>>> threads (as detailed in
>>> http://www.ibm.com/developerworks/library/l-pythrd.html) for reading the
>>> GPIOs. Do you think this would work in this situation?
>>
>> The main question IMO: the I2C bus operates at 400kHz, but how much
>> received data can it buffer? That will give you a hint as to how much
>> latency you can tolerate.
>>
>> I don't think soft threads would work at all, since they wouldn't allow
>> overlapping between frame reading and other ops. If frame reading
>> releases the GIL (as any properly implemented IO primitive in Python
>> should), then at least you can try using OS threads.
>>
>> Then, depending on the tolerable latency for I2C operation, you can try
>> to run it as an OS thread, or a separate process (if running as a
>> separate process, make sure it cannot block while sending IO to the
>> master process).
>>
>> Regards
>>
>> Antoine.
>>
>>
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: werner.vcf
Type: text/x-vcard
Size: 297 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20101201/fdfc697e/attachment-0001.vcf>