To Thread or not to Thread....?

[Antoine Pitrou]

On Wed, 1 Dec 2010 11:50:46 +0000
Jack Keegan <whatsjacksemail at gmail.com> wrote:
> Hi Antoine,
> 
> On Wed, Dec 1, 2010 at 9:24 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> >
> >
> > 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'm not sure on buffering, but I have to ask the device on the I2C bus for a
> sample each time I want one. This is done by sending out the address of the
> device on the I2C bus, waiting for a reply, then addressing the registers I
> want to read data from, then read the data. Therefore, I would need to make
> the request at the rate I require.

Sounds like you want to do this part in raw C and in a separate process,
IMO.

> > 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.
> >
> It's actually a separate piece of hardware that does the frame
> reading/encoding. I then interface to this via a DLL so I'm not sure how it
> handles things in the background. Unless I am mistaken, I have to allocate a
> chunk of memory for it to read the frames into, while I read from there.

Well, if you are the one writing the CPython interface against the DLL,
you are responsible for releasing the GIL properly.

> It's probably some sort of ring buffer implementation so I'd have to read
> the frames out and store them to disk before the next run through the buffer
> overwrites the old frames.

You have to evaluate the latency requirements there too.

I have to point out that I have no experience on embedded software, so
the advice I'm giving is out of pure common sense :)

Regards

Antoine.