Adding that bit of code seems to have fixed the problem, thanks alot!
--
http://mail.python.org/mailman/listinfo/python-list
Tuvas wrote:
> The read function used actually is from a library in C, for use over a
> CAN interface. The same library appears to work perfectly find over C.
[...]
> When nothing is happening, the thread runs pretty consistantly at 1
> second. However, when it is doing IO through this C function o
Peter Hansen wrote:
> Ivan Voras wrote:
>> Python is bad for concurrently executing/computing threads, but it
>> shouldn't be that bad - do you have lots of compute-intensive threads?
>
> Just in case anyone coming along in the future reads this statement, for
> the record I'd like to say this i
The read function used actually is from a library in C, for use over a
CAN interface. The same library appears to work perfectly find over C.
I wrote an extention module for it. The function t_config is the
threaded function that will call a function called config once per
second. Note the time.tim
Tuvas wrote:
> The stuff that it runs aren't heavily processor intensive, but rather
> consistant. It's looking to read incoming data. For some reason when it
> does this, it won't execute other threads until it's done. Hmmm.
> Perhaps I'll just have to work on a custom read function that doesn't
>
Ivan Voras:
> I mentioned it because, as far as I know the Lua's intepreter doesn't do
> implicit locking on its own, and if I want to run several threads of
> pure Lua code, it's possible if I take care of data sharing and
> synchronization myself.
Lua's interpreter will perform synchroni
The stuff that it runs aren't heavily processor intensive, but rather
consistant. It's looking to read incoming data. For some reason when it
does this, it won't execute other threads until it's done. Hmmm.
Perhaps I'll just have to work on a custom read function that doesn't
depend so much on proc
Dennis Lee Bieber wrote:
> FYI: That's GLOBAL Interpreter Lock
Yes, sorry about the confusion.
--
http://mail.python.org/mailman/listinfo/python-list
Aahz wrote:
>
> When did Perl gain threads?
At least in 2001:
http://mail.python.org/pipermail/python-dev/2001-August/017079.html
http://www.xav.com/perl/lib/Pod/perlthrtut.html
> If you read Bruce Eckel, you also know that
> the Java threading system has been buggy for something like a decade
Neil Hodgson wrote:
>Lua has coroutines rather than threads. It can cooperate with
> threading implemented by a host application or library.
I mentioned it because, as far as I know the Lua's intepreter doesn't do
implicit locking on its own, and if I want to run several threads of
pure Lu
Ivan Voras wrote:
> opinion, but by "good threading implementation" I mean that all threads
> in the application should run "natively" on the underlying (p)threads
> library at all times, without implicit serialization. For example, Java
> and perl do this, possibly also lua and C#.
Lua h
In article <[EMAIL PROTECTED]>, Ivan Voras <[EMAIL PROTECTED]> wrote:
>Peter Hansen wrote:
>>
>> Ivan, what makes you say that Python is bad for threads? Did the
>> qualifcation "concurrently executing/computing" have some significance
>> that I missed?
>
>Because of the GIL (Giant interpreter
Ivan Voras wrote:
> Peter Hansen wrote:
>>Ivan, what makes you say that Python is bad for threads? Did the
>>qualifcation "concurrently executing/computing" have some significance
>>that I missed?
>
> Because of the GIL (Giant interpreter lock).
> ...
> Much can be said about "at the same time"
Peter Hansen wrote:
> Ivan, what makes you say that Python is bad for threads? Did the
> qualifcation "concurrently executing/computing" have some significance
> that I missed?
Because of the GIL (Giant interpreter lock). It can be a matter of
opinion, but by "good threading implementation" I
Ivan Voras wrote:
> Tuvas wrote:
>>waits for a lul in the computing process. How can I ensure that this
>>does not happen? This thread uses little processing power, so it could
>>be set to a high priority, if there is a way to do this. Thanks!
>
> Python is bad for concurrently executing/computing
Tuvas wrote:
> waits for a lul in the computing process. How can I ensure that this
> does not happen? This thread uses little processing power, so it could
> be set to a high priority, if there is a way to do this. Thanks!
Python is bad for concurrently executing/computing threads, but it
shoul
Tuvas wrote:
> I have a program running several threads. One of them must be done
> every (Specified time, usually 1 second). The whole point to having a
> thread is do this. However, I've noticed the following. When there is
> another part of the program that is active, this thread slips into
> di
I have a program running several threads. One of them must be done
every (Specified time, usually 1 second). The whole point to having a
thread is do this. However, I've noticed the following. When there is
another part of the program that is active, this thread slips into
disuse, ei, it's only ran
18 matches
Mail list logo
