On 10/27/2016 12:22 PM, pozz wrote:
Anyway I don't like this approach, because the main (and single) thread
should check in_waiting every X milliseconds.
If X is too high, I could wait for the answer even if it is already
ready in the input buffer.
If X is too low, the application consumes a lot of clocks to check
in_waiting.
I would prefer to have a callback automatically called when the read
operation is complete. And I think the only method is using another
(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.
An operation within a thread will not consume less CPU clocks, however,
the scheduler will interrupt the thread and give other
threads/operations a chance to process as well.
Threads implement paralellism, not performances.
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.
You can use threads to fix that(or you can use already written working
python libraries that would mask this low level programing, it's up to you).
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.
JM
--
https://mail.python.org/mailman/listinfo/python-list
