[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Thinking about cross-platform issues. I found this, from the venerable
Tim Peters to be enlightening for python's choice of design:
It's possible to build a better Queue implementation that runs only on
POSIX systems, or only on Windows systems,
Op 2005-04-02, Paul Rubin schreef http:
Have you looked at this? A paper about adding asynchronous exceptions
to Python.
http://www.cs.williams.edu/~freund/papers/02-lwl2.ps
Looks interresting, but I doubt python will have it in the near
future. I'm very pessimitic about python development
Paul Rubin http wrote:
Nick Craig-Wood [EMAIL PROTECTED] writes:
I believe futex is the thing you want for a modern linux. Not
very portable though.
That's really cool, but I don't see how it can be a pure userspace
operation if the futex has a timeout. The kernel must need to keep
Op 2005-03-31, [EMAIL PROTECTED] schreef [EMAIL PROTECTED]:
Cool Code!
One possible sticking point is that I think select only works on
network sockets on windows. This would make the code not crossplatforn.
As far as I understand, what I did with pipes, can be done just as
fine with network
Paul L. Du Bois [EMAIL PROTECTED] writes:
Has anyone written a Queue.Queue replacement that avoids busy-waiting?
It doesn't matter if it uses os-specific APIs (eg
WaitForMultipleObjects). I did some googling around and haven't found
anything so far.
This isn't a Queue.Queue replacement, but
Have you looked at this? A paper about adding asynchronous exceptions
to Python.
http://www.cs.williams.edu/~freund/papers/02-lwl2.ps
--
http://mail.python.org/mailman/listinfo/python-list
Paul Rubin http wrote:
Antoon Pardon [EMAIL PROTECTED] writes:
I'm not sure that this would be an acceptable approach. I did the man
semop and it indicates this is part of system V IPC. This makes me
fear that semaphores will use file descriptors or other resources
that are only
Nick Craig-Wood [EMAIL PROTECTED] writes:
I believe futex is the thing you want for a modern linux. Not
very portable though.
That's really cool, but I don't see how it can be a pure userspace
operation if the futex has a timeout. The kernel must need to keep
track of the timeouts. However,
Op 2005-03-30, Paul Rubin schreef http:
I think the best bet for the short term is handling it at the C level,
with sigalarm. Another way is to have chained sigalarm handlers in
the main thread.
Possible, but I don't have the time to investigate that possibility now.
Actually there's
Antoon Pardon [EMAIL PROTECTED] writes:
I'm not sure that this would be an acceptable approach. I did the man
semop and it indicates this is part of system V IPC. This makes me
fear that semaphores will use file descriptors or other resources
that are only available in a limited amount. Not
Op 2005-03-25, Paul Rubin schreef http:
Antoon Pardon [EMAIL PROTECTED] writes:
Well maybe you could use an os.pipe as a timeout lock then. When the lock is
instantiated you put one byte in it. Aquiring the lock is implemented by
reading one byte, releasing the lock is implemented by writing a
Antoon Pardon [EMAIL PROTECTED] writes:
Well have a look at what I have written over the weekend. It uses
a seperate thread with one pipe for a wakeup mechanisme.
Thanks, I'll look at it. Why don't you use usleep instead of a pipe?
I decided over the weekend that using a separate thread with
Op 2005-03-29, Paul Rubin schreef http:
Antoon Pardon [EMAIL PROTECTED] writes:
Well have a look at what I have written over the weekend. It uses
a seperate thread with one pipe for a wakeup mechanisme.
Thanks, I'll look at it. Why don't you use usleep instead of a pipe?
Because with the
Op 2005-03-29, Antoon Pardon schreef [EMAIL PROTECTED]:
Op 2005-03-29, Paul Rubin schreef http:
Antoon Pardon [EMAIL PROTECTED] writes:
Well have a look at what I have written over the weekend. It uses
a seperate thread with one pipe for a wakeup mechanisme.
Thanks, I'll look at it. Why
Op 2005-03-29, Paul Rubin schreef http:
Antoon Pardon [EMAIL PROTECTED] writes:
I'm not going to call my solution simple, but it wastes very few
cycles. if no thread is blocked on a lock, the select will just
block until that changes. No need for some kind of polling loop.
I think I
Antoon Pardon [EMAIL PROTECTED] writes:
There needs to be a way to send signals to threads, or raise
asynchronous exceptions in them. There's been some discussion in
sourceforge about that, but the issues involved are complex.
Well I have raised this issue before and as far as I
Op 2005-03-24, Paul L. Du Bois schreef [EMAIL PROTECTED]:
Has anyone written a Queue.Queue replacement that avoids busy-waiting?
It doesn't matter if it uses os-specific APIs (eg
WaitForMultipleObjects). I did some googling around and haven't found
anything so far.
I started once, using the
Antoon Pardon [EMAIL PROTECTED] writes:
I started once, using the Timer class in the Threading Module to
break the lock. However the Timer class uses the same kind of
sleep-polling loop, to delay the exection and allow an intermediate
cancel, as the loop that is used in Queue.Queue, so that
Op 2005-03-25, Paul Rubin schreef http:
Antoon Pardon [EMAIL PROTECTED] writes:
I started once, using the Timer class in the Threading Module to
break the lock. However the Timer class uses the same kind of
sleep-polling loop, to delay the exection and allow an intermediate
cancel, as the
Antoon Pardon [EMAIL PROTECTED] writes:
I've never checked this code but it wouldn't have occurred to me that
Queue uses any kind of timeout loop. Can't it work the obvious way
with a semaphore?
And how is this semaphore going to be released if the timeout is
reached?
I meant a
Op 2005-03-25, Paul Rubin schreef http:
Antoon Pardon [EMAIL PROTECTED] writes:
I've never checked this code but it wouldn't have occurred to me that
Queue uses any kind of timeout loop. Can't it work the obvious way
with a semaphore?
And how is this semaphore going to be released if
Antoon Pardon [EMAIL PROTECTED] writes:
I meant a semaphore to synchronize the queue when adding or removing
objects.
Last I looked there was a lock used for that.
OK, that amounts to the same thing.
The loop is only for when you cant remove or add an element immediatly
and there is a
Op 2005-03-25, Paul Rubin schreef http:
Antoon Pardon [EMAIL PROTECTED] writes:
I meant a semaphore to synchronize the queue when adding or removing
objects.
Last I looked there was a lock used for that.
OK, that amounts to the same thing.
The loop is only for when you cant remove or
Has anyone written a Queue.Queue replacement that avoids busy-waiting?
It doesn't matter if it uses os-specific APIs (eg
WaitForMultipleObjects). I did some googling around and haven't found
anything so far.
Because I know someone will ask: no, the busy-waiting hasn't been a
problem in my app.
Paul L. Du Bois wrote:
Has anyone written a Queue.Queue replacement that avoids busy-waiting?
It doesn't matter if it uses os-specific APIs (eg
WaitForMultipleObjects). I did some googling around and haven't found
anything so far.
Because I know someone will ask: no, the busy-waiting hasn't been
Peter Hansen wrote:
I don't believe the term busy-wait applies here.
[Explanation]
Yes, well, you're right. I was thinking of calling it
slacker-waiting but didn't want to come off too cute.
p
--
http://mail.python.org/mailman/listinfo/python-list
26 matches
Mail list logo
