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
On 10/27/2016 02:55 PM, Chris Angelico wrote:
On Thu, Oct 27, 2016 at 11:33 PM, jmp wrote:
On 10/27/2016 01:43 PM, Chris Angelico wrote:
Blocked threads don't consume CPU time. Why would they?
ChrisA
Agreed. My point being that a blocked thread achieve nothing, except
parallelism, i.e. ot
On Thu, Oct 27, 2016 at 11:33 PM, jmp wrote:
> On 10/27/2016 01:43 PM, Chris Angelico wrote:
>>
>> Blocked threads don't consume CPU time. Why would they?
>>
>> ChrisA
>>
>
> Agreed. My point being that a blocked thread achieve nothing, except
> parallelism, i.e. other threads can be processed.
>
On 10/27/2016 01:43 PM, Chris Angelico wrote:
Blocked threads don't consume CPU time. Why would they?
ChrisA
Agreed. My point being that a blocked thread achieve nothing, except
parallelism, i.e. other threads can be processed.
To be more specific, if you compute factorial(51354) in a thre
On Thu, Oct 27, 2016 at 10:56 PM, pozz wrote:
> Yes of course, but when the backend thread calls the *blocking* function
> pyserial.read(), it *doesn't* consume CPU clocks (at least, I hope).
> The low-level implementation of pyserial.read() should move the thread in a
> "suspend" or "waiting" sta
Il 27/10/2016 13:33, jmp ha scritto:
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 to
On Thu, Oct 27, 2016 at 10:33 PM, jmp wrote:
> 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 i
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
Here is an example about threads and PyQT
https://www.youtube.com/watch?v=ivcxZSHL7jM&index=2
On 10/27/2016 01:22 PM, pozz wrote:
Il 26/10/2016 16:18, jmp ha scritto:
On 10/26/2016 02:45 PM, pozz wrote:
Il 26/10/2016 13:16, jmp ha scritto:
[...]
I suggest you write a GUI that make synchron
Il 26/10/2016 16:18, jmp ha scritto:
On 10/26/2016 02:45 PM, pozz wrote:
Il 26/10/2016 13:16, jmp ha scritto:
[...]
I suggest you write a GUI that make synchronouscalls to a remote
application, if possible. If the remote app is in python, you have
access to remote protocols already written
Chris Angelico :
> Python-the-language doesn't permit those kinds of rewrites.
[Citation needed]
Is there something here, perhaps?
https://docs.python.org/3/library/concurrency.html>
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On Thu, Oct 27, 2016 at 1:42 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>> And since Python doesn't rewrite the code, you don't have a problem.
>
> Do you mean Python or CPython?
>
> And how do you know?
Both, and I know because Python-the-language doesn't permit those
kinds of rewrites. PyPy d
Chris Angelico :
> And since Python doesn't rewrite the code, you don't have a problem.
Do you mean Python or CPython?
And how do you know?
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On Thu, Oct 27, 2016 at 1:21 AM, Marko Rauhamaa wrote:
> Analogous code in C or Java would not be guaranteed to finish if func1()
> and func2() were in different execution contexts. In fact, it would be
> almost guaranteed to hang.
>
> That is because the compiler can see that "active" cannot chan
Chris Angelico :
> On Thu, Oct 27, 2016 at 12:37 AM, Marko Rauhamaa wrote:
>> I don't know what "Global state is shared across all threads" means
>> in this context. It sounds like something that would be true for,
>> say, Java and C as well. However, those languages don't promise to
>> propagate
On 10/26/2016 02:45 PM, pozz wrote:
Il 26/10/2016 13:16, jmp ha scritto:
[...]
I suggest you write a GUI that make synchronouscalls to a remote
application, if possible. If the remote app is in python, you have
access to remote protocols already written for you, Pyro is one of them,
you can
On Thu, Oct 27, 2016 at 12:37 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Wed, Oct 26, 2016 at 11:58 PM, Marko Rauhamaa wrote:
>>> I can't think of a valid program that could take advantage of this
>>> primitive guarantee of Python's. For example, there is no "volatile"
>>> in Python so
Chris Angelico :
> On Wed, Oct 26, 2016 at 11:58 PM, Marko Rauhamaa wrote:
>> I can't think of a valid program that could take advantage of this
>> primitive guarantee of Python's. For example, there is no "volatile"
>> in Python so you can't coordinate Python threads safely without
>> proper syn
On Thu, Oct 27, 2016 at 12:02 AM, Marko Rauhamaa wrote:
> pozz :
>
>> The real problem is that retrieving status from remote device is a
>> slow operation. If the GUI thread blocks waiting for the answer, the
>> GUI blocks and the user complains.
>
> Correct. Obnoxious, blocking APIs abound.
>
> H
pozz :
> The real problem is that retrieving status from remote device is a
> slow operation. If the GUI thread blocks waiting for the answer, the
> GUI blocks and the user complains.
Correct. Obnoxious, blocking APIs abound.
However, I have usually used processes (instead of threads) to
encapsu
On Wed, Oct 26, 2016 at 11:58 PM, Marko Rauhamaa wrote:
> In practice, this coherency has been implemented in CPython with a
> global lock (GIL). CPython programs are effectively single-threaded.
> They only let go of the lock when they are performing a system call.
>
> I can't think of a valid pr
pozz :
> Il 26/10/2016 13:27, Antoon Pardon ha scritto:
>> Op 26-10-16 om 12:22 schreef pozz:
>>> Is it safe to access this variable from two different threads?
>>> Should I implement a safer and more complex mechanism? If yes, what
>>> mechanism?
>>
>> Accessing from multiple thread shouldn't be
Il 26/10/2016 13:16, jmp ha scritto:
[...]
I suggest you write a GUI that make synchronouscalls to a remote
application, if possible. If the remote app is in python, you have
access to remote protocols already written for you, Pyro is one of them,
you can skip the low level communication part
Il 26/10/2016 13:27, Antoon Pardon ha scritto:
Op 26-10-16 om 12:22 schreef pozz:
Il 26/10/2016 09:13, pozz ha scritto:
[...]
When the user press Start button (the pressed handler is in the GUI
class):
self.comm_active = True
threading.Thread(target=self.comm_thread).start()
The backend t
Op 26-10-16 om 12:22 schreef pozz:
> Il 26/10/2016 09:13, pozz ha scritto:
> > [...]
>> When the user press Start button (the pressed handler is in the GUI
>> class):
>>
>> self.comm_active = True
>> threading.Thread(target=self.comm_thread).start()
>>
>> The backend thread is:
>>
>> def comm
On 10/26/2016 12:22 PM, pozz wrote:
Il 26/10/2016 09:13, pozz ha scritto:
> [...]
When the user press Start button (the pressed handler is in the GUI
class):
self.comm_active = True
threading.Thread(target=self.comm_thread).start()
The backend thread is:
def comm_thread(self):
whil
Il 26/10/2016 09:13, pozz ha scritto:
> [...]
When the user press Start button (the pressed handler is in the GUI class):
self.comm_active = True
threading.Thread(target=self.comm_thread).start()
The backend thread is:
def comm_thread(self):
while self.comm_active:
self.device.
Il 26/10/2016 09:13, pozz ha scritto:
> [...]
What is the best approach to use in my scenario (GUI and backend
communication)?
I just found this[1] page, where the thread approach is explained with
the following code:
---
import threading
import time
from gi.repository import GLib, Gt
I'm designing a GUI application in Python (with pyGObject, so GTK). The
application communicates with a remote device (connected through RS232,
but it could be on Internet) to retrieve its status and set/get its
configuration.
When the user press "Start" button, the application starts sending
29 matches
Mail list logo
