This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients Arfrever, Giovanni.Bajo, PaulMcMillan, ReneSac, Vlado.Boza, alex, arigo, benjamin.peterson, camara, christian.heimes, cvrebert, dmalcolm, gregory.p.smith, koniiiik, lemburg, mark.dickinson, sbermeister, serhiy.storchaka, vstinner, Łukasz.Rekucki
Date 2012-11-30.22:51:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <50B93867.5020209@egenix.com>
In-reply-to <201211302327.11422.storchaka@gmail.com>
Content
On 30.11.2012 22:27, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka added the comment:
> 
>> try:
>>     mapping = {}
>>     mapping.max_collisions = 100
>>     mapping.update(source)
>> except CollisionLimitError:
>>     return 'no thank you'
> 
> May be use a more general solution?
> 
> try:
>     with run_with_timeout(timeout=100, timer=collisions_count):
>         mapping = insert_untrusted_data(source)
> except TimeoutError:
>     return 'no thank you'
> 
> (You can can use different measurement for timeout: user time, real time, ticks 
> count, collisions count, or even a user defined timer).

Sure, as long as there's a way to break into the execution,
any such method would do.

The problem is that you'd have to check for the timeout at some
point and the .update() call is running completely in C, so
the only way to break into execution is either by explicitly
adding a runtime check to the code, or use a signal (which is
a can of worms better avoided :-)).

Collision counting is one such method of detecting that
something is likely not working according to plan, but it's
really only another way of implementing the explicit runtime
check. Using other counters or timers would work just as well.

As long as you know that there are places in your code that can
produce CPU time overloads, you can address those issues.

The dictionary implementation is one such place, where you
can run into the problem, but there are usually many other
such areas in more complex applications as well, e.g. calculations
that enter endless loops for some parameters, deadlocks,
I/O operations that take unusually long (e.g. due to disk
errors), poorly written drivers of all sorts, etc. etc.

If there's a way to solve all these things in general
and without explicit runtime checks, I'd like to know :-)
History
Date User Action Args
2012-11-30 22:51:28lemburgsetrecipients: + lemburg, arigo, gregory.p.smith, mark.dickinson, vstinner, christian.heimes, benjamin.peterson, Arfrever, alex, cvrebert, dmalcolm, Giovanni.Bajo, PaulMcMillan, serhiy.storchaka, Vlado.Boza, koniiiik, sbermeister, camara, Łukasz.Rekucki, ReneSac
2012-11-30 22:51:28lemburglinkissue14621 messages
2012-11-30 22:51:28lemburgcreate