[issue22737] Provide a rejected execution model and implementations for futures.
New submission from Joshua Harlow: When a future can't be accepted by an executor that it is has been submitted to it would be really nice to throw have a type of 'RejectedExecutionException' (this is the name the java folks have used) to denote that the executors policy does not allow for further execution. Some of the reasons that further execution could be rejected (an arbitrary executor policy would be really neat). - Backlog of work to be done has reached a configurable threshold. - Resource limits reached (in concept similar to a 503 HTTP error code), come back later... This would be a great addition to allow for executor usage that does not cause resource starvation (currently executors have unbounded work queues, which is undesirable under load where a rejected execution error would be more appropriate to avoid more starvation...) -- components: Library (Lib) messages: 230058 nosy: Joshua.Harlow priority: normal severity: normal status: open title: Provide a rejected execution model and implementations for futures. type: enhancement versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue22737> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24451] Add metrics to future objects (concurrent or asyncio?)
New submission from Joshua Harlow: It would be quite useful to have some types of metrics attached to future objects so that callers could use them for various activities (scheduling repeated runs, post-analysis and such): Some of the ones that I can think would be useful: - 'submitted_at' (when the callback was submitted to the executor responsible for executing it) - 'started_at' (when the executor actually started executing the callback, which is typically sometime after it was submitted) - 'finished_at' (when the executor finished calling the callback) - elapsed [finished_at - started_at] (the elapsed runtime of the callback) Do others feel this would be useful (if so I can put up some patches)? Right now getting this information is pretty hard to get at (since the executors that exist currently do not expose this information and it is quite hard to obtain it in a reliable manner). -- components: Library (Lib) messages: 245345 nosy: Joshua.Harlow priority: normal severity: normal status: open title: Add metrics to future objects (concurrent or asyncio?) type: enhancement ___ Python tracker <http://bugs.python.org/issue24451> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24451] Add metrics to future objects (concurrent or asyncio?)
Joshua Harlow added the comment: I like the pluggable/hookable idea, that would be nice (I'm siding on the side of hookable, since I think that would be more 'elegant'). If these are just callbacks that can be hooked in for these specific 'events' that would allow me to gather the timing information that is needed (and/or other information as well). Sound like a decent plan to add these? -- ___ Python tracker <http://bugs.python.org/issue24451> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24451] Add metrics to future objects (concurrent or asyncio?)
Joshua Harlow added the comment: A prototype (WIP) of how this could work, initial thoughts welcome :-) -- keywords: +patch Added file: http://bugs.python.org/file39711/prototype.patch ___ Python tracker <http://bugs.python.org/issue24451> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24598] asyncio: add background task detecting reference cycles
Joshua Harlow added the comment: Out of curiosity what reference cycles can't be broken in various python versions? Is it documented/explained anywhere? -- nosy: +Joshua.Harlow ___ Python tracker <http://bugs.python.org/issue24598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24980] Allow for providing 'on_new_thread' callback to 'concurrent.futures.ThreadPoolExecutor'
New submission from Joshua Harlow: In situations where thread-local variables need to be setup it is quite useful to be able to hook into the thread creation process, so that as each new thread is spun up by the ThreadPoolExecutor that the threads created initially call into a provided callback (the callback can then setup thread local state as needed). -- messages: 249501 nosy: harlowja priority: normal severity: normal status: open title: Allow for providing 'on_new_thread' callback to 'concurrent.futures.ThreadPoolExecutor' ___ Python tracker <http://bugs.python.org/issue24980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24980] Allow for providing 'on_new_thread' callback to 'concurrent.futures.ThreadPoolExecutor'
Changes by Joshua Harlow : -- type: -> enhancement ___ Python tracker <http://bugs.python.org/issue24980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24980] Allow for providing 'on_new_thread' callback to 'concurrent.futures.ThreadPoolExecutor'
Changes by Joshua Harlow : -- versions: +Python 3.6 ___ Python tracker <http://bugs.python.org/issue24980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24980] Allow for providing 'on_new_thread' callback to 'concurrent.futures.ThreadPoolExecutor'
Changes by Joshua Harlow : -- components: +Library (Lib) ___ Python tracker <http://bugs.python.org/issue24980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24980] Allow for providing 'on_new_thread' callback to 'concurrent.futures.ThreadPoolExecutor'
Joshua Harlow added the comment: Initial possible patch. -- keywords: +patch type: enhancement -> Added file: http://bugs.python.org/file40318/add_future_callback.patch ___ Python tracker <http://bugs.python.org/issue24980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
