On 2016-10-27 07:33 AM, jmp wrote:
On 10/27/2016 12:22 PM, pozz wrote:
(blocking) thread. The blocking function read returns *immediately* when
all the bytes are received. And I think during blocking time, the
thread isn't consuming CPU clocks.
Threads do consume CPU clocks.
Sometimes they do but read what pozz wrote. "during blocking time, the
thread isn't consuming CPU clocks". That means that if you have two
threads with one computing π and the other blocked waiting for user
input then the first one is using CPU cycles - as many as it can get -
and the other is using none until the user enters something. This is
kind of the point of threads - only things that need cycles get cycles.
An operation within a thread will not consume less CPU clocks, however,
It will if it blocks for something. A simple sleep will also give up
the processor.
From what I understand of your context, you don't want you GUI to
"freeze" when waiting for the remote application. That's a valid concern.
And that's why you use threads. You can also use select in a state
machine loop. Depends on your model and somewhat on your preferences.
What you should not do is focus on gaining "CPU clocks". You just don't
care. It's probably not an issue. If it is, drop python and implement
your app in C.
In fact, going to C often is less of a win than you may think. Python
is pretty damn efficient if you write good code.
--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da...@vex.net
VoIP: sip:da...@vex.net
--
https://mail.python.org/mailman/listinfo/python-list
