Hi,
> I'm still confused about your app. If your producer only uses
put_nowait() and never uses yield [from],
> the consumer will never run. So you must not be describing the full story.
Just for completeness:
sure, the producer has a main loop that, in the threaded case, looks like
while Tru
On Thu, Mar 19, 2015 at 3:23 AM, Martin Teichmann <
martin.teichm...@gmail.com> wrote:
> Hi everybody,
>
> Hum, maybe this is an important issue in your application. The
>> producer should not raise an exception but *wait* until the consumer
>> read some items from the queue.
>>
>
> No. Certainly
On 18 March 2015 at 09:56, Victor Stinner wrote:
> Hi,
>
> 2015-03-18 10:31 GMT+01:00 Martin Teichmann :
> > I'm currently porting code to use asyncio. I realized that queue.Queue
> > and asyncio.Queue are very similar, which helps porting a lot, just
> > one little detail: the exceptions raised
Hi everybody,
Hum, maybe this is an important issue in your application. The
> producer should not raise an exception but *wait* until the consumer
> read some items from the queue.
>
No. Certainly not. In my application, the consumer needs always to
be fast enough (on the long run) to process
2015-03-19 10:59 GMT+01:00 Martin Teichmann :
> All works fine, only when the producer is too fast, the queue fills up
> and I get an exception.
Hum, maybe this is an important issue in your application. The
producer should not raise an exception but *wait* until the consumer
read some items from
Hi Guido, Hi everyone,
There's also another possible use case for your proposal, where you
> actually have code that can either use asyncio or the threading queue
> module in the same try/except block, and you'd like to catch both
> exceptions. But this seems problematic, since you'd have to ha
Martin, what is the exact mistake you made that prompted you to post this
proposal? I'm guessing you had an except clause that named a non-existent
exception, and you didn't have a test case that triggered that specific
except clause. But did you have the old queue module's Full/Empty there, or
did
Hi Victor,
Yes, exceptions have a different name because the queue module only
> contains queues, whereas asyncio is a large package which contains a
> lot of various classes: subprocesses, sockets, pipes, etc. "Full"
> would be confusing (pipe full? stream buffer full? etc.), "QueueFull"
> is
Hi,
2015-03-18 10:31 GMT+01:00 Martin Teichmann :
> I'm currently porting code to use asyncio. I realized that queue.Queue
> and asyncio.Queue are very similar, which helps porting a lot, just
> one little detail: the exceptions raised by queue.Queue are called
> Empty and Full, while in asyncio t
Hi everybody,
I'm currently porting code to use asyncio. I realized that queue.Queue
and asyncio.Queue are very similar, which helps porting a lot, just
one little detail: the exceptions raised by queue.Queue are called
Empty and Full, while in asyncio the are called QueueEmpty and
QueueFull. Pers
10 matches
Mail list logo
