)]}'
{"specs/eventlet-to-native-threads.rst":[{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"b9aac7dc87f00d0bba334b560e40f04a4a6bb7b2","unresolved":false,"context_lines":[{"line_number":208,"context_line":"Where *in-process* caches are used in openstack they will need to be examined"},{"line_number":209,"context_line":"to determine if they are thread-safe; certain checks need to be done to verify"},{"line_number":210,"context_line":"this. For example to ensure that a thread is not iterating over a"},{"line_number":211,"context_line":"dictionary (which could be the potential cache) and another thread is removin"},{"line_number":212,"context_line":"items from that same dictionary (this is not a thread-safe operation). These"},{"line_number":213,"context_line":"types of checks will likely need to be done by each project (and would be a"},{"line_number":214,"context_line":"great type of thing to report back on in the previously mentioned per-project"}],"source_content_type":"text/x-rst","patch_set":12,"id":"ba7be1f8_900adfd0","line":211,"updated":"2015-02-20 15:15:12.000000000","message":"typo: removing","commit_id":"556b5eff0b11543f87b3ae58284c2f83e7a0f956"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"b9aac7dc87f00d0bba334b560e40f04a4a6bb7b2","unresolved":false,"context_lines":[{"line_number":209,"context_line":"to determine if they are thread-safe; certain checks need to be done to verify"},{"line_number":210,"context_line":"this. For example to ensure that a thread is not iterating over a"},{"line_number":211,"context_line":"dictionary (which could be the potential cache) and another thread is removin"},{"line_number":212,"context_line":"items from that same dictionary (this is not a thread-safe operation). These"},{"line_number":213,"context_line":"types of checks will likely need to be done by each project (and would be a"},{"line_number":214,"context_line":"great type of thing to report back on in the previously mentioned per-project"},{"line_number":215,"context_line":"analysis)."}],"source_content_type":"text/x-rst","patch_set":12,"id":"ba7be1f8_70d3ab38","line":212,"updated":"2015-02-20 15:15:12.000000000","message":"Well, in general, it\u0027s easier to protect the whole cache with a single lock (acquire the lock to read or write).","commit_id":"556b5eff0b11543f87b3ae58284c2f83e7a0f956"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"ad1618fb840e9749cc0f2ee8bf83bdc566b12af4","unresolved":false,"context_lines":[{"line_number":209,"context_line":"to determine if they are thread-safe; certain checks need to be done to verify"},{"line_number":210,"context_line":"this. For example to ensure that a thread is not iterating over a"},{"line_number":211,"context_line":"dictionary (which could be the potential cache) and another thread is removin"},{"line_number":212,"context_line":"items from that same dictionary (this is not a thread-safe operation). These"},{"line_number":213,"context_line":"types of checks will likely need to be done by each project (and would be a"},{"line_number":214,"context_line":"great type of thing to report back on in the previously mentioned per-project"},{"line_number":215,"context_line":"analysis)."}],"source_content_type":"text/x-rst","patch_set":12,"id":"ba7be1f8_4a1d130f","line":212,"in_reply_to":"ba7be1f8_70d3ab38","updated":"2015-02-20 16:50:13.000000000","message":"Agreed.\n\nThankfully the following now exists to:\n\nhttps://github.com/openstack/oslo.concurrency/blob/master/oslo_concurrency/lockutils.py#L495\n\nSo people that need that can use it...","commit_id":"556b5eff0b11543f87b3ae58284c2f83e7a0f956"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"b9aac7dc87f00d0bba334b560e40f04a4a6bb7b2","unresolved":false,"context_lines":[{"line_number":239,"context_line":"Alternatives"},{"line_number":240,"context_line":"------------"},{"line_number":241,"context_line":""},{"line_number":242,"context_line":"#. Switch over to `asyncio`_ via `153298`_ (and do not use threads)."},{"line_number":243,"context_line":"#. Switch over to `asyncio`_ via `153298`_ (and use it in hybrid mode with"},{"line_number":244,"context_line":"   the usage of threads when needed/appropriate)."},{"line_number":245,"context_line":"#. Keep on using eventlet + its warts (and live with it)."}],"source_content_type":"text/x-rst","patch_set":12,"id":"ba7be1f8_7579ddfb","line":242,"updated":"2015-02-20 15:15:12.000000000","message":"I don\u0027t think that using asyncio without threads makes sense. For example, loop.getaddrinfo() is implemented with a thread pool. I want to use asyncio with threads!","commit_id":"556b5eff0b11543f87b3ae58284c2f83e7a0f956"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"ad1618fb840e9749cc0f2ee8bf83bdc566b12af4","unresolved":false,"context_lines":[{"line_number":239,"context_line":"Alternatives"},{"line_number":240,"context_line":"------------"},{"line_number":241,"context_line":""},{"line_number":242,"context_line":"#. Switch over to `asyncio`_ via `153298`_ (and do not use threads)."},{"line_number":243,"context_line":"#. Switch over to `asyncio`_ via `153298`_ (and use it in hybrid mode with"},{"line_number":244,"context_line":"   the usage of threads when needed/appropriate)."},{"line_number":245,"context_line":"#. Keep on using eventlet + its warts (and live with it)."}],"source_content_type":"text/x-rst","patch_set":12,"id":"ba7be1f8_2a729f7c","line":242,"in_reply_to":"ba7be1f8_7579ddfb","updated":"2015-02-20 16:50:13.000000000","message":"Ok dokie, will remove this then.","commit_id":"556b5eff0b11543f87b3ae58284c2f83e7a0f956"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"b9aac7dc87f00d0bba334b560e40f04a4a6bb7b2","unresolved":false,"context_lines":[{"line_number":291,"context_line":"For certain *compute* (and not I/O) intensive projects (keystone?) they"},{"line_number":292,"context_line":"may not see much advantage of switching to native threads (due to the GIL)"},{"line_number":293,"context_line":"and they may have to try alternate techniques to solve there architectural"},{"line_number":294,"context_line":"limitations (scaling out with processes...). This is **not** expected to be"},{"line_number":295,"context_line":"new territory for these projects as they *should have* hit the same kind of"},{"line_number":296,"context_line":"issues already with eventlet at scale (if they didn\u0027t that project seems"},{"line_number":297,"context_line":"somewhat questionable)."}],"source_content_type":"text/x-rst","patch_set":12,"id":"ba7be1f8_9079ff95","line":294,"updated":"2015-02-20 15:15:12.000000000","message":"The concurrent.futures can be used for threads, but also for processes. It\u0027s a nicer API on top of multiprocessing.\n\nI don\u0027t know if it\u0027s better to spawn multiple processes of the daemon, or to spawn processes from a daemon. At least, you now have the choice ;-)\n\nYou may mention it, since you plan to use the concurrent.futures module.","commit_id":"556b5eff0b11543f87b3ae58284c2f83e7a0f956"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"ec01f516a125fe4f7b0e24b76a3805f74ba12493","unresolved":false,"context_lines":[{"line_number":291,"context_line":"For certain *compute* (and not I/O) intensive projects (keystone?) they"},{"line_number":292,"context_line":"may not see much advantage of switching to native threads (due to the GIL)"},{"line_number":293,"context_line":"and they may have to try alternate techniques to solve there architectural"},{"line_number":294,"context_line":"limitations (scaling out with processes...). This is **not** expected to be"},{"line_number":295,"context_line":"new territory for these projects as they *should have* hit the same kind of"},{"line_number":296,"context_line":"issues already with eventlet at scale (if they didn\u0027t that project seems"},{"line_number":297,"context_line":"somewhat questionable)."}],"source_content_type":"text/x-rst","patch_set":12,"id":"ba7be1f8_a7b6c8da","line":294,"in_reply_to":"ba7be1f8_9079ff95","updated":"2015-02-20 16:35:27.000000000","message":"Sure. Will add.\n\nAlthough I\u0027ve found the process executor somewhat buggy (although afaik this is being fixed):\n\nhttp://docs.openstack.org/developer/taskflow/engines.html#parallel (see note there about using a process pool executor).","commit_id":"556b5eff0b11543f87b3ae58284c2f83e7a0f956"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"b9aac7dc87f00d0bba334b560e40f04a4a6bb7b2","unresolved":false,"context_lines":[{"line_number":352,"context_line":"Using this section to highlight things we need to decide that aren\u0027t"},{"line_number":353,"context_line":"settled as of yet."},{"line_number":354,"context_line":""},{"line_number":355,"context_line":"* Request PTLs feedback/analysis on there own projects thread-safety."},{"line_number":356,"context_line":"* Investigate (to some level) libraries used and expected thread-safety."},{"line_number":357,"context_line":"* Refactor `service.py`_ to use native threads (and refactor associated"},{"line_number":358,"context_line":"  unit tests accordingly); or replace it with some pre-existing library (or"}],"source_content_type":"text/x-rst","patch_set":12,"id":"ba7be1f8_f0dcfb76","line":355,"updated":"2015-02-20 15:15:12.000000000","message":"Do you have suggestions of projects to experiment threads on them? For example, nova is maybe not a good candidate since it\u0027s one of the largest and most complex project. Maybe keystone?","commit_id":"556b5eff0b11543f87b3ae58284c2f83e7a0f956"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"ec01f516a125fe4f7b0e24b76a3805f74ba12493","unresolved":false,"context_lines":[{"line_number":352,"context_line":"Using this section to highlight things we need to decide that aren\u0027t"},{"line_number":353,"context_line":"settled as of yet."},{"line_number":354,"context_line":""},{"line_number":355,"context_line":"* Request PTLs feedback/analysis on there own projects thread-safety."},{"line_number":356,"context_line":"* Investigate (to some level) libraries used and expected thread-safety."},{"line_number":357,"context_line":"* Refactor `service.py`_ to use native threads (and refactor associated"},{"line_number":358,"context_line":"  unit tests accordingly); or replace it with some pre-existing library (or"}],"source_content_type":"text/x-rst","patch_set":12,"id":"ba7be1f8_07edd4c3","line":355,"in_reply_to":"ba7be1f8_f0dcfb76","updated":"2015-02-20 16:35:27.000000000","message":"Unsure, open to ideas/suggestions...","commit_id":"556b5eff0b11543f87b3ae58284c2f83e7a0f956"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"b9aac7dc87f00d0bba334b560e40f04a4a6bb7b2","unresolved":false,"context_lines":[{"line_number":358,"context_line":"  unit tests accordingly); or replace it with some pre-existing library (or"},{"line_number":359,"context_line":"  make one of the ones that already exists better)?"},{"line_number":360,"context_line":"* Switch the default oslo.messaging executor used to the threadpool"},{"line_number":361,"context_line":"  executor..."},{"line_number":362,"context_line":"* Run tests..."},{"line_number":363,"context_line":"* See what fails (due to thread issues or races or other)..."},{"line_number":364,"context_line":"* Fix issues related to thread safety (or other) and repeat..."}],"source_content_type":"text/x-rst","patch_set":12,"id":"ba7be1f8_b058c3fb","line":361,"updated":"2015-02-20 15:15:12.000000000","message":"In my asyncio spec, I proposed to do all the asyncio development in a separated branch. Since you expect bugs with threads, you might also use a branch. Or maybe it\u0027s possible to keep the same code base for eventlet and threads and have a global switch?","commit_id":"556b5eff0b11543f87b3ae58284c2f83e7a0f956"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"ec01f516a125fe4f7b0e24b76a3805f74ba12493","unresolved":false,"context_lines":[{"line_number":358,"context_line":"  unit tests accordingly); or replace it with some pre-existing library (or"},{"line_number":359,"context_line":"  make one of the ones that already exists better)?"},{"line_number":360,"context_line":"* Switch the default oslo.messaging executor used to the threadpool"},{"line_number":361,"context_line":"  executor..."},{"line_number":362,"context_line":"* Run tests..."},{"line_number":363,"context_line":"* See what fails (due to thread issues or races or other)..."},{"line_number":364,"context_line":"* Fix issues related to thread safety (or other) and repeat..."}],"source_content_type":"text/x-rst","patch_set":12,"id":"ba7be1f8_a7dde816","line":361,"in_reply_to":"ba7be1f8_b058c3fb","updated":"2015-02-20 16:35:27.000000000","message":"Unsure, open to ideas/suggestions...","commit_id":"556b5eff0b11543f87b3ae58284c2f83e7a0f956"},{"author":{"_account_id":4715,"name":"Angus Salkeld","email":"asalkeld@redhat.com","username":"asalkeld"},"change_message_id":"eb403733b8a24b398fca21701279e11a758321fd","unresolved":false,"context_lines":[{"line_number":200,"context_line":"projects thread-safety (it would be nice to do a similar analysis of any"},{"line_number":201,"context_line":"libraries that are being used). This kind of proactive (instead of reactive)"},{"line_number":202,"context_line":"analysis would help in determining issues ahead of time, instead of when those"},{"line_number":203,"context_line":"libraries or projects start causing hard to detect bugs/errors/issues."},{"line_number":204,"context_line":""},{"line_number":205,"context_line":"Caches"},{"line_number":206,"context_line":"******"}],"source_content_type":"text/x-rst","patch_set":13,"id":"ba7be1f8_0f9b8918","line":203,"updated":"2015-03-04 00:40:14.000000000","message":"oslo.config and SIGHUP come to mind, but could be solved in the library.","commit_id":"2f78ff0fa8ed0cf1b5d0e0022500418ee9fbd1df"}],"specs/sew-some-threads.rst":[{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"bfa0e5b60971ff1f3514a9069e8877dcacc8f10a","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Sew over eventlet + patching with threads"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Problem description"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_4e093f30","line":8,"updated":"2015-02-18 17:30:28.000000000","message":"I don\u0027t know what this idiom (or pun?) means. Could you update the title so it is more clear what this proposal is for?","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"ded785fa62707489169d272390d8ab785bca0629","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Sew over eventlet + patching with threads"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Problem description"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_c4fb18bc","line":8,"in_reply_to":"da86d52c_4e093f30","updated":"2015-02-19 00:48:15.000000000","message":"Sewing + patches (threads u sew with).\n\nGuess I should use one that\u0027s not a pun though ;)","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"bfa0e5b60971ff1f3514a9069e8877dcacc8f10a","unresolved":false,"context_lines":[{"line_number":22,"context_line":"calls and make them transparently asynchronous. It has become more and more"},{"line_number":23,"context_line":"apparent that this way forward is not desirable and certain options have"},{"line_number":24,"context_line":"started to appear to allow for getting away from that model (and to something"},{"line_number":25,"context_line":"where the pasture is more green)."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"One such option being `asyncio`_ which is being discussed at `153298`_ (and"},{"line_number":28,"context_line":"which we shall not summarize here as that review goes into more than"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_cd08b02f","line":25,"updated":"2015-02-18 17:30:28.000000000","message":"It would be good here to include some of the issues we\u0027ve had. A few I can think of off the top of my head are: third-party libraries not interacting well with eventlet\u0027s patching, poor support for Python 3, and errors due to patching at the wrong point (usually too late) in execution.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"2113ce9d12ed46b54fe507f7c213aa3c43aa258a","unresolved":false,"context_lines":[{"line_number":47,"context_line":"First there would be required changes to make the dispatching \u0027receiving\u0027"},{"line_number":48,"context_line":"libraries use threads (these are mostly all the non-wsgi services that"},{"line_number":49,"context_line":"exist in openstack), one of the key libraries required to accommodate this"},{"line_number":50,"context_line":"would be `oslo.messaging`_. That library recently acquired a threadpool"},{"line_number":51,"context_line":"executor (see `70914`_) that can spin off requests into a future"},{"line_number":52,"context_line":"compatible `executor`_ (this module added in python 3.2 has a `backport`_ that"},{"line_number":53,"context_line":"has been used for quite a while in openstack projects, primarily"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_9b28d698","line":50,"updated":"2015-02-18 00:25:01.000000000","message":"Is the new thread executor compatible with eventlet? I don\u0027t think that eventlet likes native threads :-(","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"b3bff734704a7e567982db6e763a763a9a27fd07","unresolved":false,"context_lines":[{"line_number":47,"context_line":"First there would be required changes to make the dispatching \u0027receiving\u0027"},{"line_number":48,"context_line":"libraries use threads (these are mostly all the non-wsgi services that"},{"line_number":49,"context_line":"exist in openstack), one of the key libraries required to accommodate this"},{"line_number":50,"context_line":"would be `oslo.messaging`_. That library recently acquired a threadpool"},{"line_number":51,"context_line":"executor (see `70914`_) that can spin off requests into a future"},{"line_number":52,"context_line":"compatible `executor`_ (this module added in python 3.2 has a `backport`_ that"},{"line_number":53,"context_line":"has been used for quite a while in openstack projects, primarily"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_a7165947","line":50,"in_reply_to":"da86d52c_9b28d698","updated":"2015-02-18 01:27:59.000000000","message":"I\u0027d hope so, eventlet patches the threading library so I don\u0027t see why it wouldn\u0027t... Unless that patching of the threading library is busted (if it is we are in a bigger hole than I thought).\n\nAll the futures executor with thread pools is @ https://code.google.com/p/pythonfutures/source/browse/concurrent/futures/thread.py (this is the backport version); it doesn\u0027t use anything special that eventlet couldn\u0027t monkeypatch out... Queues, some condition objects and threads (all things that eventlet is monkeypatching away).","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"bfa0e5b60971ff1f3514a9069e8877dcacc8f10a","unresolved":false,"context_lines":[{"line_number":47,"context_line":"First there would be required changes to make the dispatching \u0027receiving\u0027"},{"line_number":48,"context_line":"libraries use threads (these are mostly all the non-wsgi services that"},{"line_number":49,"context_line":"exist in openstack), one of the key libraries required to accommodate this"},{"line_number":50,"context_line":"would be `oslo.messaging`_. That library recently acquired a threadpool"},{"line_number":51,"context_line":"executor (see `70914`_) that can spin off requests into a future"},{"line_number":52,"context_line":"compatible `executor`_ (this module added in python 3.2 has a `backport`_ that"},{"line_number":53,"context_line":"has been used for quite a while in openstack projects, primarily"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_08447645","line":50,"in_reply_to":"da86d52c_9b28d698","updated":"2015-02-18 17:30:28.000000000","message":"If we are talking about removing the use of eventlet in favor of threads, why do we care if the threading executor supports eventlet?","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"fa5dfbdfdc629080a89bd11cd71298b01147089c","unresolved":false,"context_lines":[{"line_number":47,"context_line":"First there would be required changes to make the dispatching \u0027receiving\u0027"},{"line_number":48,"context_line":"libraries use threads (these are mostly all the non-wsgi services that"},{"line_number":49,"context_line":"exist in openstack), one of the key libraries required to accommodate this"},{"line_number":50,"context_line":"would be `oslo.messaging`_. That library recently acquired a threadpool"},{"line_number":51,"context_line":"executor (see `70914`_) that can spin off requests into a future"},{"line_number":52,"context_line":"compatible `executor`_ (this module added in python 3.2 has a `backport`_ that"},{"line_number":53,"context_line":"has been used for quite a while in openstack projects, primarily"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_f3164d48","line":50,"in_reply_to":"da86d52c_a7165947","updated":"2015-02-18 09:30:28.000000000","message":"On Python 3, eventlet replaces threading.Lock, but the new object behaves differently for negative timeout. I have a pending pull request to fix this:\nhttps://github.com/eventlet/eventlet/pull/187\n\nInitially, I wrote the patch to fix threading.Condition, but I had to fix threading.RLock and threading.Lock too :-p threading.Condition and threading.RLock issues only impact Python 3.3+, threading.Lock issue impacts Python 3.2+.\n\nI hope that the issue will be fixed quickly. OpenStack has more and more voting Python 3 gates.\n\nThere are maybe other eventlet issues with threads, but I stopped my tests on these issues because they blocked me.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"4bb70603fbcd448db54271d6bfcfdad40c062130","unresolved":false,"context_lines":[{"line_number":47,"context_line":"First there would be required changes to make the dispatching \u0027receiving\u0027"},{"line_number":48,"context_line":"libraries use threads (these are mostly all the non-wsgi services that"},{"line_number":49,"context_line":"exist in openstack), one of the key libraries required to accommodate this"},{"line_number":50,"context_line":"would be `oslo.messaging`_. That library recently acquired a threadpool"},{"line_number":51,"context_line":"executor (see `70914`_) that can spin off requests into a future"},{"line_number":52,"context_line":"compatible `executor`_ (this module added in python 3.2 has a `backport`_ that"},{"line_number":53,"context_line":"has been used for quite a while in openstack projects, primarily"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_41c1f1e2","line":50,"in_reply_to":"da86d52c_f3164d48","updated":"2015-02-18 15:44:17.000000000","message":"What\u0027s a negative timeout :-P\n\nIs that like going backwards in time ;)\n\nGood to know though, I haven\u0027t seen much usage that I think would be affected by said negative timeout, but I\u0027ll keep an eye out for it.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"2113ce9d12ed46b54fe507f7c213aa3c43aa258a","unresolved":false,"context_lines":[{"line_number":52,"context_line":"compatible `executor`_ (this module added in python 3.2 has a `backport`_ that"},{"line_number":53,"context_line":"has been used for quite a while in openstack projects, primarily"},{"line_number":54,"context_line":"by `taskflow engines`_ and `tooz`_ but likely also by others?). This spinning"},{"line_number":55,"context_line":"off of requests into a **per-request** thread pool will allow that"},{"line_number":56,"context_line":"thread to block, unblock, and yield to other threads (just as it would"},{"line_number":57,"context_line":"normally) by taking advantage of the in-built ability of threads to yield to"},{"line_number":58,"context_line":"others when doing blocking I/O (or acquiring some shared lock...) by using"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_3b77ead5","line":55,"updated":"2015-02-18 00:25:01.000000000","message":"Does it mean that each request has its own pool? Why not sharing the pool with all requests? The purpose of the pool is to reduce the cost of creating/destroying a thread, no?","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"fa5dfbdfdc629080a89bd11cd71298b01147089c","unresolved":false,"context_lines":[{"line_number":52,"context_line":"compatible `executor`_ (this module added in python 3.2 has a `backport`_ that"},{"line_number":53,"context_line":"has been used for quite a while in openstack projects, primarily"},{"line_number":54,"context_line":"by `taskflow engines`_ and `tooz`_ but likely also by others?). This spinning"},{"line_number":55,"context_line":"off of requests into a **per-request** thread pool will allow that"},{"line_number":56,"context_line":"thread to block, unblock, and yield to other threads (just as it would"},{"line_number":57,"context_line":"normally) by taking advantage of the in-built ability of threads to yield to"},{"line_number":58,"context_line":"others when doing blocking I/O (or acquiring some shared lock...) by using"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_536b99b8","line":55,"in_reply_to":"da86d52c_272269a3","updated":"2015-02-18 09:30:28.000000000","message":"Ooooh ok :-) I prefer that. A thread per request is a common thread, and using a thread pool for that would be efficient.\n\nDoes the size of the thread pool limit the number of concurrent request? If yes, it\u0027s a nice size effect. It\u0027s good to be able to limit the number of threads. If you want to queue more requests, you have various options for that.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"b3bff734704a7e567982db6e763a763a9a27fd07","unresolved":false,"context_lines":[{"line_number":52,"context_line":"compatible `executor`_ (this module added in python 3.2 has a `backport`_ that"},{"line_number":53,"context_line":"has been used for quite a while in openstack projects, primarily"},{"line_number":54,"context_line":"by `taskflow engines`_ and `tooz`_ but likely also by others?). This spinning"},{"line_number":55,"context_line":"off of requests into a **per-request** thread pool will allow that"},{"line_number":56,"context_line":"thread to block, unblock, and yield to other threads (just as it would"},{"line_number":57,"context_line":"normally) by taking advantage of the in-built ability of threads to yield to"},{"line_number":58,"context_line":"others when doing blocking I/O (or acquiring some shared lock...) by using"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_272269a3","line":55,"in_reply_to":"da86d52c_3b77ead5","updated":"2015-02-18 01:27:59.000000000","message":"Sorry meant a per-request thread (sharing a common pool); good catch.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"4bb70603fbcd448db54271d6bfcfdad40c062130","unresolved":false,"context_lines":[{"line_number":52,"context_line":"compatible `executor`_ (this module added in python 3.2 has a `backport`_ that"},{"line_number":53,"context_line":"has been used for quite a while in openstack projects, primarily"},{"line_number":54,"context_line":"by `taskflow engines`_ and `tooz`_ but likely also by others?). This spinning"},{"line_number":55,"context_line":"off of requests into a **per-request** thread pool will allow that"},{"line_number":56,"context_line":"thread to block, unblock, and yield to other threads (just as it would"},{"line_number":57,"context_line":"normally) by taking advantage of the in-built ability of threads to yield to"},{"line_number":58,"context_line":"others when doing blocking I/O (or acquiring some shared lock...) by using"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_414f3192","line":55,"in_reply_to":"da86d52c_536b99b8","updated":"2015-02-18 15:44:17.000000000","message":"Ya, I think this is how it works right now to with oslo.messaging to.\n\nThe code/config @ https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/_executors/base.py#L20 + the number of processes I think is the upper limit on how many requests an app can serve at once afaik (but I might be wrong).","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1669,"name":"Julien Danjou","display_name":"jd","email":"julien@danjou.info","username":"jdanjou"},"change_message_id":"02d5206c7938eefdba5259ec1d2a14630d2fe8a5","unresolved":false,"context_lines":[{"line_number":58,"context_line":"others when doing blocking I/O (or acquiring some shared lock...) by using"},{"line_number":59,"context_line":"the operating system scheduler to do the work for us (python will automatically"},{"line_number":60,"context_line":"yield to other threads when a thread is blocking on some sort of I/O or lock"},{"line_number":61,"context_line":"or other). Since most libraries **should** already be able to work in this type"},{"line_number":62,"context_line":"of mode this makes the change noted above that much less dramatic (and likely"},{"line_number":63,"context_line":"just requires us to tweak the thread pool size to a reasonable value; and"},{"line_number":64,"context_line":"potentially fix some libraries shared usage of data, if any is encountered)."}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_69c181e3","line":61,"updated":"2015-02-18 14:20:14.000000000","message":"That\u0027s not really Python that\u0027s yielding anything, that\u0027s a operating system thing – and it might not be \"yield\" as several can run in parallel if you have multiple CPU.\n\nI know you know that, it\u0027s just that I don\u0027t want people reading that to be confused. :)","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"a33df5797d5dabc97a482cfa86cd058f806d1dd1","unresolved":false,"context_lines":[{"line_number":58,"context_line":"others when doing blocking I/O (or acquiring some shared lock...) by using"},{"line_number":59,"context_line":"the operating system scheduler to do the work for us (python will automatically"},{"line_number":60,"context_line":"yield to other threads when a thread is blocking on some sort of I/O or lock"},{"line_number":61,"context_line":"or other). Since most libraries **should** already be able to work in this type"},{"line_number":62,"context_line":"of mode this makes the change noted above that much less dramatic (and likely"},{"line_number":63,"context_line":"just requires us to tweak the thread pool size to a reasonable value; and"},{"line_number":64,"context_line":"potentially fix some libraries shared usage of data, if any is encountered)."}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_ca67bbe8","line":61,"in_reply_to":"da86d52c_69c181e3","updated":"2015-02-18 14:47:02.000000000","message":"Python has a role, especially the GIL. The GIL indirectly orders threads: threads are executed in the same order than they ask for the GIL.The GIL can be released explicitly (ex: on I/O), but also after a \"timeout\".\n\nOn Python 2, the \"timeout\" is a number of instructions (default: 100):\nhttps://docs.python.org/2/library/sys.html#sys.setcheckinterval\n\nOn Python 3, the \"timeout\" is really based on time (default: 5 ms):\nhttps://docs.python.org/dev/library/sys.html#sys.setswitchinterval\n\nWhen nobody holds the GIL, the operating system can do its real job to schedule threads. But I don\u0027t think that it\u0027s something common in CPython because of the GIL :-(","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"4bb70603fbcd448db54271d6bfcfdad40c062130","unresolved":false,"context_lines":[{"line_number":58,"context_line":"others when doing blocking I/O (or acquiring some shared lock...) by using"},{"line_number":59,"context_line":"the operating system scheduler to do the work for us (python will automatically"},{"line_number":60,"context_line":"yield to other threads when a thread is blocking on some sort of I/O or lock"},{"line_number":61,"context_line":"or other). Since most libraries **should** already be able to work in this type"},{"line_number":62,"context_line":"of mode this makes the change noted above that much less dramatic (and likely"},{"line_number":63,"context_line":"just requires us to tweak the thread pool size to a reasonable value; and"},{"line_number":64,"context_line":"potentially fix some libraries shared usage of data, if any is encountered)."}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_541c5166","line":61,"in_reply_to":"da86d52c_ca67bbe8","updated":"2015-02-18 15:44:17.000000000","message":"Agreed to all the above, there is a tick/switch interval that got better in py3.x afaik (with the better GIL);  maybe I should pick a different word instead of yield to avoid some of that confusion around \u0027yield\u0027 and its multiple meanings...","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"2113ce9d12ed46b54fe507f7c213aa3c43aa258a","unresolved":false,"context_lines":[{"line_number":61,"context_line":"or other). Since most libraries **should** already be able to work in this type"},{"line_number":62,"context_line":"of mode this makes the change noted above that much less dramatic (and likely"},{"line_number":63,"context_line":"just requires us to tweak the thread pool size to a reasonable value; and"},{"line_number":64,"context_line":"potentially fix some libraries shared usage of data, if any is encountered)."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"For those that *really really* want a `eventlet`_ compatible `executor`_"},{"line_number":67,"context_line":"taskflow has created one that uses eventlet pools/queues (and can likely"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_563ab5cd","line":64,"updated":"2015-02-18 00:25:01.000000000","message":"Do you have an idea of libraries used by OpenStack are thread-safe? Is it an issue if a library is not thread-safe?\n\nThere are two kinds of thread-safety issues:\n\n- an object cannot used by two threads: you can workaround this issue by using an object per thread and be careful in your own code\n\n- the library uses some internal structures (ex: cache) which is not thread-safe: in this case, you have to put a global lock on the whole library to wokaround the issue, or fix the issue upstream","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"b71634dbf724205e6e4f6821f527e34756e93d91","unresolved":false,"context_lines":[{"line_number":61,"context_line":"or other). Since most libraries **should** already be able to work in this type"},{"line_number":62,"context_line":"of mode this makes the change noted above that much less dramatic (and likely"},{"line_number":63,"context_line":"just requires us to tweak the thread pool size to a reasonable value; and"},{"line_number":64,"context_line":"potentially fix some libraries shared usage of data, if any is encountered)."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"For those that *really really* want a `eventlet`_ compatible `executor`_"},{"line_number":67,"context_line":"taskflow has created one that uses eventlet pools/queues (and can likely"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_87723548","line":64,"in_reply_to":"da86d52c_473afdcd","updated":"2015-02-18 01:30:49.000000000","message":"As for this one; if we are using a library that needs help, we should fix it. We should be good custodians of things we use, and IMHO if we find issues like these, yes, we help upstream fix it; it is our (and everyones) duty to do this I believe...","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1669,"name":"Julien Danjou","display_name":"jd","email":"julien@danjou.info","username":"jdanjou"},"change_message_id":"02d5206c7938eefdba5259ec1d2a14630d2fe8a5","unresolved":false,"context_lines":[{"line_number":61,"context_line":"or other). Since most libraries **should** already be able to work in this type"},{"line_number":62,"context_line":"of mode this makes the change noted above that much less dramatic (and likely"},{"line_number":63,"context_line":"just requires us to tweak the thread pool size to a reasonable value; and"},{"line_number":64,"context_line":"potentially fix some libraries shared usage of data, if any is encountered)."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"For those that *really really* want a `eventlet`_ compatible `executor`_"},{"line_number":67,"context_line":"taskflow has created one that uses eventlet pools/queues (and can likely"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_89407560","line":64,"in_reply_to":"da86d52c_53c71998","updated":"2015-02-18 14:20:14.000000000","message":"I\u0027m pretty sure most libraries are not thread safe but might work as long as we keep their usage not shared between threads.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"b3bff734704a7e567982db6e763a763a9a27fd07","unresolved":false,"context_lines":[{"line_number":61,"context_line":"or other). Since most libraries **should** already be able to work in this type"},{"line_number":62,"context_line":"of mode this makes the change noted above that much less dramatic (and likely"},{"line_number":63,"context_line":"just requires us to tweak the thread pool size to a reasonable value; and"},{"line_number":64,"context_line":"potentially fix some libraries shared usage of data, if any is encountered)."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"For those that *really really* want a `eventlet`_ compatible `executor`_"},{"line_number":67,"context_line":"taskflow has created one that uses eventlet pools/queues (and can likely"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_473afdcd","line":64,"in_reply_to":"da86d52c_563ab5cd","updated":"2015-02-18 01:27:59.000000000","message":"I would hope most of them are, but I am not sure. It is a good point; if they aren\u0027t that seems like bugs against those libraries.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"fa5dfbdfdc629080a89bd11cd71298b01147089c","unresolved":false,"context_lines":[{"line_number":61,"context_line":"or other). Since most libraries **should** already be able to work in this type"},{"line_number":62,"context_line":"of mode this makes the change noted above that much less dramatic (and likely"},{"line_number":63,"context_line":"just requires us to tweak the thread pool size to a reasonable value; and"},{"line_number":64,"context_line":"potentially fix some libraries shared usage of data, if any is encountered)."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"For those that *really really* want a `eventlet`_ compatible `executor`_"},{"line_number":67,"context_line":"taskflow has created one that uses eventlet pools/queues (and can likely"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_53c71998","line":64,"in_reply_to":"da86d52c_87723548","updated":"2015-02-18 09:30:28.000000000","message":"Sure, it\u0027s better to enhance all these libraries. But I\u0027m asking because if they are too many issues, it maybe means that threads are not the best option for OpenStack, and that OpenStack may also have issues with threads.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"d17309edcec031a568939476b38bd81be04fa24b","unresolved":false,"context_lines":[{"line_number":61,"context_line":"or other). Since most libraries **should** already be able to work in this type"},{"line_number":62,"context_line":"of mode this makes the change noted above that much less dramatic (and likely"},{"line_number":63,"context_line":"just requires us to tweak the thread pool size to a reasonable value; and"},{"line_number":64,"context_line":"potentially fix some libraries shared usage of data, if any is encountered)."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"For those that *really really* want a `eventlet`_ compatible `executor`_"},{"line_number":67,"context_line":"taskflow has created one that uses eventlet pools/queues (and can likely"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_1463b91a","line":64,"in_reply_to":"da86d52c_89407560","updated":"2015-02-18 15:54:48.000000000","message":"Right and I think we do a pretty decent job of that already (not sharing stuff that much between threads, using little if/any shared data...). There likely would be some new discoveries of shared-data and needed fixes around those, but it feels like we have been doing an ok job at avoiding this kind of stuff.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"2113ce9d12ed46b54fe507f7c213aa3c43aa258a","unresolved":false,"context_lines":[{"line_number":82,"context_line":"the default ability to stop green-threads by \u0027force\u0027 (this will not work with"},{"line_number":83,"context_line":"regular threads as u can not stop them by \u0027force\u0027 but must request them to stop"},{"line_number":84,"context_line":"and ``join()`` on them; this likely *should* be the default for green-threads"},{"line_number":85,"context_line":"anyway as forcefully terminating a thread is typically bad practice)."},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"WSGI"},{"line_number":88,"context_line":"~~~~"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_118047be","line":85,"updated":"2015-02-18 00:25:01.000000000","message":"Not being able to \"stop\" a thread may be an issue. In asyncio, you can put a timeout on *any* asynchronous operation (just wrap it into asyncio.wait_for), and you can cancel a task.\n\nBut I\u0027m not sure that the current code which (implicitly or explicitly?) drops pending tasks \"by force\" is correct :-)","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"7ad99a548c2fef421dae1f035d212f74933c00b4","unresolved":false,"context_lines":[{"line_number":82,"context_line":"the default ability to stop green-threads by \u0027force\u0027 (this will not work with"},{"line_number":83,"context_line":"regular threads as u can not stop them by \u0027force\u0027 but must request them to stop"},{"line_number":84,"context_line":"and ``join()`` on them; this likely *should* be the default for green-threads"},{"line_number":85,"context_line":"anyway as forcefully terminating a thread is typically bad practice)."},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"WSGI"},{"line_number":88,"context_line":"~~~~"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_a679da94","line":85,"in_reply_to":"da86d52c_088c76d6","updated":"2015-02-18 17:47:11.000000000","message":"\u003e What sorts of tasks do we expect to be canceling?\n\nI remember that timeout on neutron calls while spawning a VM in nova was a common error in my test infras.\n\nYou must use timeouts on operations, otherwise your server may become slower and slower and waste resources.\n\nThere are probably other kinds of \"cancellation\".\n\n\u003e I\u0027m not sure simply killing the thread/task is the best way\n\nI\u0027m sorry, my comment was specific to asyncio which handles cancellation nicely. I don\u0027t know how it should be handled with threads.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"b3bff734704a7e567982db6e763a763a9a27fd07","unresolved":false,"context_lines":[{"line_number":82,"context_line":"the default ability to stop green-threads by \u0027force\u0027 (this will not work with"},{"line_number":83,"context_line":"regular threads as u can not stop them by \u0027force\u0027 but must request them to stop"},{"line_number":84,"context_line":"and ``join()`` on them; this likely *should* be the default for green-threads"},{"line_number":85,"context_line":"anyway as forcefully terminating a thread is typically bad practice)."},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"WSGI"},{"line_number":88,"context_line":"~~~~"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_c7742d9e","line":85,"in_reply_to":"da86d52c_118047be","updated":"2015-02-18 01:27:59.000000000","message":"Cancellation of tasks in progress never seems like a good idea, even with asyncio u should let a task finish what its doing, instead of trying to force it to quit in a unknown (and likely unexpected/unhandled way). If the thread doesn\u0027t ever finish, imho u got bigger problems/bugs and u should fix them appropriatly.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"4bb70603fbcd448db54271d6bfcfdad40c062130","unresolved":false,"context_lines":[{"line_number":82,"context_line":"the default ability to stop green-threads by \u0027force\u0027 (this will not work with"},{"line_number":83,"context_line":"regular threads as u can not stop them by \u0027force\u0027 but must request them to stop"},{"line_number":84,"context_line":"and ``join()`` on them; this likely *should* be the default for green-threads"},{"line_number":85,"context_line":"anyway as forcefully terminating a thread is typically bad practice)."},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"WSGI"},{"line_number":88,"context_line":"~~~~"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_747dd56c","line":85,"in_reply_to":"da86d52c_330b85d7","updated":"2015-02-18 15:44:17.000000000","message":"Ok, as long as the task is able to know that it got cancelled (via timeout error); outright cancellation of tasks (via say forcing a greenlet to stop) in code that was never made to be cancelled (aka all the stuff eventlet monkey patches) was more of what I was thinking about.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"7ad99a548c2fef421dae1f035d212f74933c00b4","unresolved":false,"context_lines":[{"line_number":82,"context_line":"the default ability to stop green-threads by \u0027force\u0027 (this will not work with"},{"line_number":83,"context_line":"regular threads as u can not stop them by \u0027force\u0027 but must request them to stop"},{"line_number":84,"context_line":"and ``join()`` on them; this likely *should* be the default for green-threads"},{"line_number":85,"context_line":"anyway as forcefully terminating a thread is typically bad practice)."},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"WSGI"},{"line_number":88,"context_line":"~~~~"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_c61c0e69","line":85,"in_reply_to":"da86d52c_747dd56c","updated":"2015-02-18 17:47:11.000000000","message":"In asyncio, when you cancel a task, the task gets a CancelledError exception. You are free to decide how to handle it: replace it to a new exception and ignore it! Since the task is awaken by the exception, it can execute code to cleanup everything.\nhttps://docs.python.org/dev/library/asyncio-task.html#asyncio.Task.cancel\n\nIf I understood correctly, it\u0027s very different from eventlet which can kill silently a greenthread.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"bfa0e5b60971ff1f3514a9069e8877dcacc8f10a","unresolved":false,"context_lines":[{"line_number":82,"context_line":"the default ability to stop green-threads by \u0027force\u0027 (this will not work with"},{"line_number":83,"context_line":"regular threads as u can not stop them by \u0027force\u0027 but must request them to stop"},{"line_number":84,"context_line":"and ``join()`` on them; this likely *should* be the default for green-threads"},{"line_number":85,"context_line":"anyway as forcefully terminating a thread is typically bad practice)."},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"WSGI"},{"line_number":88,"context_line":"~~~~"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_088c76d6","line":85,"in_reply_to":"da86d52c_747dd56c","updated":"2015-02-18 17:30:28.000000000","message":"What sorts of tasks do we expect to be canceling? Long running operations that call out to other processes, API requests to services that don\u0027t reply, or something else? Those do seem like things we need to handle, but as Josh says I\u0027m not sure simply killing the thread/task is the best way because it doesn\u0027t provide an opportunity to clean up partially completed work.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"cc49c2179564d7884177981d183b2e8cc4a6ae66","unresolved":false,"context_lines":[{"line_number":82,"context_line":"the default ability to stop green-threads by \u0027force\u0027 (this will not work with"},{"line_number":83,"context_line":"regular threads as u can not stop them by \u0027force\u0027 but must request them to stop"},{"line_number":84,"context_line":"and ``join()`` on them; this likely *should* be the default for green-threads"},{"line_number":85,"context_line":"anyway as forcefully terminating a thread is typically bad practice)."},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"WSGI"},{"line_number":88,"context_line":"~~~~"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_1d1d910f","line":85,"in_reply_to":"da86d52c_c61c0e69","updated":"2015-02-18 19:45:40.000000000","message":"I wonder how much of the code that is being created to be asyncio compatible is actually handling this error (since as far as I understand it, every usage of \u0027yield from\u0027 needs to be wrapped in a \u0027CancelledError\u0027? and the code needs to handle this occurring?).\n\n+2\n\nThough to what eventlet does that is similar being bad (since the code it monkey patches has no idea that a exception like \u0027CancelledError\u0027 maybe raised, at least code created for asyncio should be somewhat aware that \u0027CancelledError\u0027(s) may happen)","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"fa5dfbdfdc629080a89bd11cd71298b01147089c","unresolved":false,"context_lines":[{"line_number":82,"context_line":"the default ability to stop green-threads by \u0027force\u0027 (this will not work with"},{"line_number":83,"context_line":"regular threads as u can not stop them by \u0027force\u0027 but must request them to stop"},{"line_number":84,"context_line":"and ``join()`` on them; this likely *should* be the default for green-threads"},{"line_number":85,"context_line":"anyway as forcefully terminating a thread is typically bad practice)."},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"WSGI"},{"line_number":88,"context_line":"~~~~"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_330b85d7","line":85,"in_reply_to":"da86d52c_c7742d9e","updated":"2015-02-18 09:30:28.000000000","message":"Cancelling a task in asyncio is a very common operation if you use run tasks with a timeout. On timeout, a TimeoutError exception is raised, which usually cancel indirectly tasks. For example, you expect a reply in less than 60 seconds, and cancel the current request on timeout.\n\nCancellation is just a convinient way to write code. You can write code without timeout. For example, you can use a loop with a sleep (polling) and trigger manually the timeout (check the deadline at each loop iteration).\n\nSince Python 3.3, subprocess.Popen.communicate() also accepts an optional timeout. There is the \"subprocess32\" backport project if you need timeout on communicate().\n\nSince Python 3.2, threading.Lock.acquire() accept an optional timeout. Unlikely, on older Python versions, you have to implement it manually with a busy loop (polling) whereas the feature is supported by the operating system :-(","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"bfa0e5b60971ff1f3514a9069e8877dcacc8f10a","unresolved":false,"context_lines":[{"line_number":90,"context_line":"The other bigger change is what to do about the wsgi entrypoints requests"},{"line_number":91,"context_line":"(not the same per-request as above, but a web-service request vs a message"},{"line_number":92,"context_line":"queue received request). For this option I would prefer to let"},{"line_number":93,"context_line":"applications such as apache or others handle the request as they see fit"},{"line_number":94,"context_line":"and just make sure that our applications provide wsgi entrypoints that are"},{"line_number":95,"context_line":"stateless and can be horizontally scaled as needed (aka remove all eventlet"},{"line_number":96,"context_line":"and thread ... semantics and usage from these entrypoints entirely). If at"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_284a1a83","line":93,"updated":"2015-02-18 17:30:28.000000000","message":"+1\n\nThere are quite a few options for deploying WSGI applications. We should take advantage of them.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"bfa0e5b60971ff1f3514a9069e8877dcacc8f10a","unresolved":false,"context_lines":[{"line_number":97,"context_line":"deployment time a deployer wants to use apache (or wants to use something"},{"line_number":98,"context_line":"else) or wants to shove the wsgi entrypoint into a *hacky* (and typically"},{"line_number":99,"context_line":"non-standard/questionably solid IMHO) eventlet wsgi server that is up to there"},{"line_number":100,"context_line":"own deployment decisions/choices."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Periodics"},{"line_number":103,"context_line":"~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_686972f7","line":100,"updated":"2015-02-18 17:30:28.000000000","message":"A lot of our API services use oslo.messaging to start an operation in another service in the background. Would you recommend using the blocking executor for those, rather than the threading executor?","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"bd525db6fac55b13cd70eae322bc4ec7e566bdb4","unresolved":false,"context_lines":[{"line_number":97,"context_line":"deployment time a deployer wants to use apache (or wants to use something"},{"line_number":98,"context_line":"else) or wants to shove the wsgi entrypoint into a *hacky* (and typically"},{"line_number":99,"context_line":"non-standard/questionably solid IMHO) eventlet wsgi server that is up to there"},{"line_number":100,"context_line":"own deployment decisions/choices."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Periodics"},{"line_number":103,"context_line":"~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_1274a0cd","line":100,"in_reply_to":"da86d52c_686972f7","updated":"2015-02-18 19:37:50.000000000","message":"Sounds fair to me (but I guess it depends on the application and when the response is expected (and what the contents of it are)); if the wsgi app wants to maintain a thread (or pool) that\u0027s sole job is to \u0027async\u0027 send things from a wsgi request (initiated by some wsgi server) to a target somewhere in some messaging server (non-wsgi) then that seems fair (aka the cast from wsgi server to somewhere else). If though it needs to really be blocking (and should block the wsgi response, aka the call case) then that should probably always use something like the blocking executor.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":100,"name":"Johannes Erdfelt","email":"johannes@erdfelt.com","username":"johannes.erdfelt"},"change_message_id":"2555104257165a4b7220e3f564a4cd1ee3524ae7","unresolved":false,"context_lines":[{"line_number":122,"context_line":"determine next run-times)."},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"Locks locks and more locks"},{"line_number":125,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Since I think this deserves its own section I am going to talk a little about"},{"line_number":128,"context_line":"it here. In the various openstack projects there *may* be a set of issues"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_02a34500","line":125,"updated":"2015-02-19 16:57:40.000000000","message":"It might be worthwhile to make it clearer and separate this into shared state internal to a process and external (SQL databases, XenServer, libvirt, etc).\n\nThe former is the real concern here. The latter is a problem even with eventlet and nothing changes there.\n\nEnumerating the internal shared state would probably require a complete audit of all code. Leaning on just my experience with the Nova code, I can\u0027t think of much internal shared state. Most code pulls data from a database and then operates on that.\n\nCaches are likely the biggest source of internal shared state, however those are generally easy to make safe (and in some cases are already safe). In Nova, the scheduler might need some extra attention, but I think it uses the database for shared state mostly.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"58df815ce4824764cf8526f74d456ef159d700b3","unresolved":false,"context_lines":[{"line_number":122,"context_line":"determine next run-times)."},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"Locks locks and more locks"},{"line_number":125,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Since I think this deserves its own section I am going to talk a little about"},{"line_number":128,"context_line":"it here. In the various openstack projects there *may* be a set of issues"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_bd4e1c6d","line":125,"in_reply_to":"da86d52c_02a34500","updated":"2015-02-19 17:03:06.000000000","message":"Will do, thanks :)","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"2113ce9d12ed46b54fe507f7c213aa3c43aa258a","unresolved":false,"context_lines":[{"line_number":132,"context_line":"workers (and/or shared-nothing process that themselves contain shared-nothing"},{"line_number":133,"context_line":"workers). Where appropriate it may be required to add more locks around shared"},{"line_number":134,"context_line":"state (where/if it exists) to avoid these types of issues that were previously"},{"line_number":135,"context_line":"being hidden by eventlet usage. Projects/libraries that we use that we uncover"},{"line_number":136,"context_line":"to be not thread-safe may also be required to be fixed/adjusted to be"},{"line_number":137,"context_line":"thread-safe (although we likely have seen most of the problematic areas already"},{"line_number":138,"context_line":"due to how any races around I/O like function would have already been"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_7648992d","line":135,"updated":"2015-02-18 00:25:01.000000000","message":"Valgrind has tools to detect race conditions for applications written in C. Do you know if Python has similar tools? At least a static analysis of the code? Or dynamically?","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"b3bff734704a7e567982db6e763a763a9a27fd07","unresolved":false,"context_lines":[{"line_number":132,"context_line":"workers (and/or shared-nothing process that themselves contain shared-nothing"},{"line_number":133,"context_line":"workers). Where appropriate it may be required to add more locks around shared"},{"line_number":134,"context_line":"state (where/if it exists) to avoid these types of issues that were previously"},{"line_number":135,"context_line":"being hidden by eventlet usage. Projects/libraries that we use that we uncover"},{"line_number":136,"context_line":"to be not thread-safe may also be required to be fixed/adjusted to be"},{"line_number":137,"context_line":"thread-safe (although we likely have seen most of the problematic areas already"},{"line_number":138,"context_line":"due to how any races around I/O like function would have already been"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_e73131a3","line":135,"in_reply_to":"da86d52c_7648992d","updated":"2015-02-18 01:27:59.000000000","message":"Unsure.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"2113ce9d12ed46b54fe507f7c213aa3c43aa258a","unresolved":false,"context_lines":[{"line_number":136,"context_line":"to be not thread-safe may also be required to be fixed/adjusted to be"},{"line_number":137,"context_line":"thread-safe (although we likely have seen most of the problematic areas already"},{"line_number":138,"context_line":"due to how any races around I/O like function would have already been"},{"line_number":139,"context_line":"uncovered)."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Backdoors"},{"line_number":142,"context_line":"~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_9616edf0","line":139,"updated":"2015-02-18 00:25:01.000000000","message":"Well, a green thread can only be interrupted on I/O (or \"explicitly\", with eventlet.time(0) for example),  whereas a thread can simply be interrupted anywhere, between two instructions, atomic instructions or not. I expect more race conditions, and more tricky issues, using threads than using threads.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"fa5dfbdfdc629080a89bd11cd71298b01147089c","unresolved":false,"context_lines":[{"line_number":136,"context_line":"to be not thread-safe may also be required to be fixed/adjusted to be"},{"line_number":137,"context_line":"thread-safe (although we likely have seen most of the problematic areas already"},{"line_number":138,"context_line":"due to how any races around I/O like function would have already been"},{"line_number":139,"context_line":"uncovered)."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Backdoors"},{"line_number":142,"context_line":"~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_b3ff7533","line":139,"in_reply_to":"da86d52c_878cf581","updated":"2015-02-18 09:30:28.000000000","message":"\u003e Except python doesn\u0027t let 2 threads run in the interpreter at the same time (aka the GIL) so why would this be a issue?\n\nConsider this simple example:\n\ndef generate_unique_id1(self):\n    id \u003d self._unique_id   # so called \"shared data\"\n    # I prey for the GIL god, please protect us against race conditions!\n    self._unique_id +\u003d 1\n    return id\n\nThis code is *not* thread-safe. Python can decide to interrupt the code before \"self._unique_id +\u003d 1\". If a second thread also calls generate_unique_id(), the generated identifier is not more \"unique\" \u003d\u003e you get a race condition.\n\nOn this example, you must protect self._unique_id with a lock:\n\ndef generate_unique_id2(self):\n    with self._lock:\n        id \u003d self._unique_id\n        # I don\u0027t care if I\u0027m interrupted, I\u0027m not more afraid\n        self._unique_id +\u003d 1\n    return id\n\nThe problem is that basic tests may not trigger the race condition since the time window when the race condition can occur is *very short*: the thread must be interrupted exactly between \"id \u003d self._unique_id\" and \"self._unique_id +\u003d 1\".\n\nMurphy\u0027s Law: if your code is not thread-safe, it will fail on production under high system load, and you will be unable to reproduce the bug on a simple setup. The worst case is when you are unable to reproduce the race condition even with stress tests :-(\n\n--\n\nWith eventlet, race conditions can occur in less case. Example:\n\ndef generate_unique_id3(self):\n    id \u003d self._unique_id   # so called \"shared data\"\n    do_something()\n    self._unique_id +\u003d 1\n    return id\n\nYou only get a race condition if do_something() switchs to a new green thread. It can occur implicitly if do_something() uses an I/O operation, or explicitly, using eventlet.sleep(0) for example.\n\nWith threads, the race condition is more likely with generate_unique_id3() than with generate_unique_id1() since the time window is larger, and there is risk than generate_unique_id3() relases explicitly the GIL.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"b3bff734704a7e567982db6e763a763a9a27fd07","unresolved":false,"context_lines":[{"line_number":136,"context_line":"to be not thread-safe may also be required to be fixed/adjusted to be"},{"line_number":137,"context_line":"thread-safe (although we likely have seen most of the problematic areas already"},{"line_number":138,"context_line":"due to how any races around I/O like function would have already been"},{"line_number":139,"context_line":"uncovered)."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Backdoors"},{"line_number":142,"context_line":"~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_878cf581","line":139,"in_reply_to":"da86d52c_9616edf0","updated":"2015-02-18 01:27:59.000000000","message":"Except python doesn\u0027t let 2 threads run in the interpreter at the same time (aka the GIL) so why would this be a issue? Python (unless I guess we start to use jython/pypy? which I believe isn\u0027t bound by this) I thought is still bound to this limitation, so u wouldn\u0027t get things like two python instructions (the pyc compiled ones) running at the same time...? If we were using jython, ya, I would think we\u0027d have to start to use a bunch of java atomic objects here in many many places we wouldn\u0027t of previously.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"4bb70603fbcd448db54271d6bfcfdad40c062130","unresolved":false,"context_lines":[{"line_number":136,"context_line":"to be not thread-safe may also be required to be fixed/adjusted to be"},{"line_number":137,"context_line":"thread-safe (although we likely have seen most of the problematic areas already"},{"line_number":138,"context_line":"due to how any races around I/O like function would have already been"},{"line_number":139,"context_line":"uncovered)."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Backdoors"},{"line_number":142,"context_line":"~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_74107500","line":139,"in_reply_to":"da86d52c_b3ff7533","updated":"2015-02-18 15:44:17.000000000","message":"Agreed, that kind of stuff needs locks if its mutating that kind of shared data with that kind of usage.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"2113ce9d12ed46b54fe507f7c213aa3c43aa258a","unresolved":false,"context_lines":[{"line_number":151,"context_line":"Alternatives"},{"line_number":152,"context_line":"------------"},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"#. Switch over to `asyncio`_ via `153298`_."},{"line_number":155,"context_line":"#. Keep on using eventlet + its warts (and live with it)."},{"line_number":156,"context_line":"#. Watch paint peel and/or watch grass grow."},{"line_number":157,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_7186e3ba","line":154,"updated":"2015-02-18 00:25:01.000000000","message":"I would prefer to not have to choose between threads and asyncio. IMO both approaches are complementary. They solve different problems.\n\nAt least, I would prefer to have some working code to be able to compare both approaches, instead of having to compare specs with unclear points (like performances, concrete plan to switch code from eventlet to asyncio/threads, issues with external libraries, etc.).","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"b3bff734704a7e567982db6e763a763a9a27fd07","unresolved":false,"context_lines":[{"line_number":151,"context_line":"Alternatives"},{"line_number":152,"context_line":"------------"},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"#. Switch over to `asyncio`_ via `153298`_."},{"line_number":155,"context_line":"#. Keep on using eventlet + its warts (and live with it)."},{"line_number":156,"context_line":"#. Watch paint peel and/or watch grass grow."},{"line_number":157,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_a7ead9d5","line":154,"in_reply_to":"da86d52c_7186e3ba","updated":"2015-02-18 01:27:59.000000000","message":"Well the thing to me is that our code is already designed to have green thread pools, to be share-nothing green threads, spawned from green thread pools created by worker processes that are themselves share-nothing. So all that is needed is to replace all the prior mentions of \u0027green\u0027 with the non-green version and see what happens. That seems simpler than having to revamp (syntax, code architecture...) to asyncio and/or trillous.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"2113ce9d12ed46b54fe507f7c213aa3c43aa258a","unresolved":false,"context_lines":[{"line_number":152,"context_line":"------------"},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"#. Switch over to `asyncio`_ via `153298`_."},{"line_number":155,"context_line":"#. Keep on using eventlet + its warts (and live with it)."},{"line_number":156,"context_line":"#. Watch paint peel and/or watch grass grow."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"Data model impact"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_56e71512","line":155,"updated":"2015-02-18 00:25:01.000000000","message":"Would it be possible to use eventlet without monkey-patching?","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"b3bff734704a7e567982db6e763a763a9a27fd07","unresolved":false,"context_lines":[{"line_number":152,"context_line":"------------"},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"#. Switch over to `asyncio`_ via `153298`_."},{"line_number":155,"context_line":"#. Keep on using eventlet + its warts (and live with it)."},{"line_number":156,"context_line":"#. Watch paint peel and/or watch grass grow."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"Data model impact"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_c7e98d1b","line":155,"in_reply_to":"da86d52c_56e71512","updated":"2015-02-18 01:27:59.000000000","message":"Sure. Although what\u0027s the point? I\u0027m not sure what its buying us then; why not just regular threads (both will yield to other threads/greenlets when blocking on I/O, both won\u0027t run at the same time in the python interpreter); is this just to avoid the operating system scheduler (if so, meh)?","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"d17309edcec031a568939476b38bd81be04fa24b","unresolved":false,"context_lines":[{"line_number":152,"context_line":"------------"},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"#. Switch over to `asyncio`_ via `153298`_."},{"line_number":155,"context_line":"#. Keep on using eventlet + its warts (and live with it)."},{"line_number":156,"context_line":"#. Watch paint peel and/or watch grass grow."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"Data model impact"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_5705330e","line":155,"in_reply_to":"da86d52c_86686dbb","updated":"2015-02-18 15:54:48.000000000","message":"Agreed, let\u0027s not go back to defered.callback(blah)....\n\nI\u0027ll add this info though, for those that might want it. Thanks.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"fa5dfbdfdc629080a89bd11cd71298b01147089c","unresolved":false,"context_lines":[{"line_number":152,"context_line":"------------"},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"#. Switch over to `asyncio`_ via `153298`_."},{"line_number":155,"context_line":"#. Keep on using eventlet + its warts (and live with it)."},{"line_number":156,"context_line":"#. Watch paint peel and/or watch grass grow."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"Data model impact"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_86686dbb","line":155,"in_reply_to":"da86d52c_c7e98d1b","updated":"2015-02-18 09:30:28.000000000","message":"Some developers may ask the question when reading the spec, so it would be nice to mention it, and maybe explain why you consider that this alternative is worse.\n\nIf we choose to move away from eventlet monkey-patching, I agree that eventlet with explicit async programming is not the most exciting choice. I would prefer threads or asyncio than eventlet without monkey-patching. eventlet without monkey-patching means callbacks.Trust me, you don\u0027t want to go back into the callback hell (previously design when Nova used Twisted/Tornado).","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"bfa0e5b60971ff1f3514a9069e8877dcacc8f10a","unresolved":false,"context_lines":[{"line_number":160,"context_line":""},{"line_number":161,"context_line":"NA"},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"REST API impact"},{"line_number":164,"context_line":"---------------"},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"NA"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_63d99555","line":163,"updated":"2015-02-18 17:30:28.000000000","message":"The API itself won\u0027t change, but the implementation might and the deployment will if we move away from eventlet\u0027s WSGI container to something else.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"bd525db6fac55b13cd70eae322bc4ec7e566bdb4","unresolved":false,"context_lines":[{"line_number":160,"context_line":""},{"line_number":161,"context_line":"NA"},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"REST API impact"},{"line_number":164,"context_line":"---------------"},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"NA"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_b2403460","line":163,"in_reply_to":"da86d52c_63d99555","updated":"2015-02-18 19:37:50.000000000","message":"Agreed.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"bfa0e5b60971ff1f3514a9069e8877dcacc8f10a","unresolved":false,"context_lines":[{"line_number":192,"context_line":"see fit and address bottlenecks that we find (as long as those bottlenecks"},{"line_number":193,"context_line":"are not python itself, which they might actually be...)."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"For certain *compute* (and not I/O) intensive projects (keystone?) they"},{"line_number":196,"context_line":"may not see much advantage of switching to native threads (due to the GIL)"},{"line_number":197,"context_line":"and they may have to try alternate techniques to solve there architectural"},{"line_number":198,"context_line":"limitations (scaling out with processes...). This is **not** expected to be"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_8383e901","line":195,"updated":"2015-02-18 17:30:28.000000000","message":"Keystone is able to be deployed with or without eventlet today.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"bd525db6fac55b13cd70eae322bc4ec7e566bdb4","unresolved":false,"context_lines":[{"line_number":192,"context_line":"see fit and address bottlenecks that we find (as long as those bottlenecks"},{"line_number":193,"context_line":"are not python itself, which they might actually be...)."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"For certain *compute* (and not I/O) intensive projects (keystone?) they"},{"line_number":196,"context_line":"may not see much advantage of switching to native threads (due to the GIL)"},{"line_number":197,"context_line":"and they may have to try alternate techniques to solve there architectural"},{"line_number":198,"context_line":"limitations (scaling out with processes...). This is **not** expected to be"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_72315c0a","line":195,"in_reply_to":"da86d52c_8383e901","updated":"2015-02-18 19:37:50.000000000","message":"Right, it\u0027d be useful to get some keystone folks to comment here on how that has worked out for them. I\u0027m pretty sure they fit into the bucket that can be summarized as \u0027just make wsgi app that scales horizontally, let wsgi container scale out however it wants, profit...\u0027","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"2113ce9d12ed46b54fe507f7c213aa3c43aa258a","unresolved":false,"context_lines":[{"line_number":193,"context_line":"are not python itself, which they might actually be...)."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"For certain *compute* (and not I/O) intensive projects (keystone?) they"},{"line_number":196,"context_line":"may not see much advantage of switching to native threads (due to the GIL)"},{"line_number":197,"context_line":"and they may have to try alternate techniques to solve there architectural"},{"line_number":198,"context_line":"limitations (scaling out with processes...). This is **not** expected to be"},{"line_number":199,"context_line":"new territory for these projects as they *should have* hit the same kind of"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_7b8fa2cd","line":196,"updated":"2015-02-18 00:25:01.000000000","message":"It may even be worse, see http://www.dabeaz.com/GIL/. Splitting a CPU-bound task (written in pure Python) into multiple threads may slow down the task instead of making it faster, just because of the GIL. I hope that CPU-bound is written in C and release the GIL!\n\nAccording to the discussion on the asyncio spec, you will probably have almost similar performances between eventlet and threads. I expect some speedup for code releasing the GIL.\n\nBy the way, does OpenStack already use threads in some places, maybe for performances?","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"d9be30a23f43b7212f14bcddc463cd899bfdbcce","unresolved":false,"context_lines":[{"line_number":193,"context_line":"are not python itself, which they might actually be...)."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"For certain *compute* (and not I/O) intensive projects (keystone?) they"},{"line_number":196,"context_line":"may not see much advantage of switching to native threads (due to the GIL)"},{"line_number":197,"context_line":"and they may have to try alternate techniques to solve there architectural"},{"line_number":198,"context_line":"limitations (scaling out with processes...). This is **not** expected to be"},{"line_number":199,"context_line":"new territory for these projects as they *should have* hit the same kind of"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_47f59ceb","line":196,"in_reply_to":"da86d52c_07c72599","updated":"2015-02-18 02:11:59.000000000","message":"Tooz also uses the futures thread pool (and threads itself when interacting with kazoo, the library); so that\u0027 another one that deserves mentioning here. I haven\u0027t heard it\u0027s gone badly...","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"b3bff734704a7e567982db6e763a763a9a27fd07","unresolved":false,"context_lines":[{"line_number":193,"context_line":"are not python itself, which they might actually be...)."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"For certain *compute* (and not I/O) intensive projects (keystone?) they"},{"line_number":196,"context_line":"may not see much advantage of switching to native threads (due to the GIL)"},{"line_number":197,"context_line":"and they may have to try alternate techniques to solve there architectural"},{"line_number":198,"context_line":"limitations (scaling out with processes...). This is **not** expected to be"},{"line_number":199,"context_line":"new territory for these projects as they *should have* hit the same kind of"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_07c72599","line":196,"in_reply_to":"da86d52c_7b8fa2cd","updated":"2015-02-18 01:27:59.000000000","message":"Yes, that\u0027s why CPU bound stuff should do something else entirely IMHO. It should scale out via other known and understood methods to bypass these problems.\n\nAs for openstack projects using threads; taskflow (the library) uses the above mentioned future \u0026 pool executors (and it\u0027s worked out fine). Those that are using it have afaik worked out fine, other projects I\u0027m not sure. Maybe someone else can comment.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"bfa0e5b60971ff1f3514a9069e8877dcacc8f10a","unresolved":false,"context_lines":[{"line_number":195,"context_line":"For certain *compute* (and not I/O) intensive projects (keystone?) they"},{"line_number":196,"context_line":"may not see much advantage of switching to native threads (due to the GIL)"},{"line_number":197,"context_line":"and they may have to try alternate techniques to solve there architectural"},{"line_number":198,"context_line":"limitations (scaling out with processes...). This is **not** expected to be"},{"line_number":199,"context_line":"new territory for these projects as they *should have* hit the same kind of"},{"line_number":200,"context_line":"issues already with eventlet at scale (if they didn\u0027t that project seems"},{"line_number":201,"context_line":"somewhat questionable)."}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_c39fa14e","line":198,"updated":"2015-02-18 17:30:28.000000000","message":"The multiprocessing module might be a good fit for those cases.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"bd525db6fac55b13cd70eae322bc4ec7e566bdb4","unresolved":false,"context_lines":[{"line_number":195,"context_line":"For certain *compute* (and not I/O) intensive projects (keystone?) they"},{"line_number":196,"context_line":"may not see much advantage of switching to native threads (due to the GIL)"},{"line_number":197,"context_line":"and they may have to try alternate techniques to solve there architectural"},{"line_number":198,"context_line":"limitations (scaling out with processes...). This is **not** expected to be"},{"line_number":199,"context_line":"new territory for these projects as they *should have* hit the same kind of"},{"line_number":200,"context_line":"issues already with eventlet at scale (if they didn\u0027t that project seems"},{"line_number":201,"context_line":"somewhat questionable)."}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_921df075","line":198,"in_reply_to":"da86d52c_c39fa14e","updated":"2015-02-18 19:37:50.000000000","message":"Agreed, or if something like keystone, then just let the wsgi container do it for u (using concepts similar to multiprocessing, say when that container is apache using preforking).","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"2113ce9d12ed46b54fe507f7c213aa3c43aa258a","unresolved":false,"context_lines":[{"line_number":204,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"* MySQL-Python (assuming in ``C`` land it releases the GIL correctly and"},{"line_number":207,"context_line":"  protects its internals from threads correctly as well...)."},{"line_number":208,"context_line":"* Other ``C`` libraries that we may use?"},{"line_number":209,"context_line":"* All those libraries that are already built to (and prepared to) work"},{"line_number":210,"context_line":"  with threads."}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_d6886524","line":207,"updated":"2015-02-18 00:25:01.000000000","message":"Agreed. Any code releasing the GIL will make the program much faster when executed in native threads.\n\nBy the way, a lot of Python functions release the GIL. Almost all I/O operations. hashlib, socket, zlib, bzip2, ... modules also release the GIL.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"bfa0e5b60971ff1f3514a9069e8877dcacc8f10a","unresolved":false,"context_lines":[{"line_number":204,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"* MySQL-Python (assuming in ``C`` land it releases the GIL correctly and"},{"line_number":207,"context_line":"  protects its internals from threads correctly as well...)."},{"line_number":208,"context_line":"* Other ``C`` libraries that we may use?"},{"line_number":209,"context_line":"* All those libraries that are already built to (and prepared to) work"},{"line_number":210,"context_line":"  with threads."}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_c3cde15e","line":207,"in_reply_to":"da86d52c_27cc29bb","updated":"2015-02-18 17:30:28.000000000","message":"I thought another motivation for moving off of MySQL-Python was Python 3 support.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"bd525db6fac55b13cd70eae322bc4ec7e566bdb4","unresolved":false,"context_lines":[{"line_number":204,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"* MySQL-Python (assuming in ``C`` land it releases the GIL correctly and"},{"line_number":207,"context_line":"  protects its internals from threads correctly as well...)."},{"line_number":208,"context_line":"* Other ``C`` libraries that we may use?"},{"line_number":209,"context_line":"* All those libraries that are already built to (and prepared to) work"},{"line_number":210,"context_line":"  with threads."}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_3202840c","line":207,"in_reply_to":"da86d52c_c3cde15e","updated":"2015-02-18 19:37:50.000000000","message":"Ah good point, forgot about that one.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"b3bff734704a7e567982db6e763a763a9a27fd07","unresolved":false,"context_lines":[{"line_number":204,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"* MySQL-Python (assuming in ``C`` land it releases the GIL correctly and"},{"line_number":207,"context_line":"  protects its internals from threads correctly as well...)."},{"line_number":208,"context_line":"* Other ``C`` libraries that we may use?"},{"line_number":209,"context_line":"* All those libraries that are already built to (and prepared to) work"},{"line_number":210,"context_line":"  with threads."}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_27cc29bb","line":207,"in_reply_to":"da86d52c_d6886524","updated":"2015-02-18 01:27:59.000000000","message":"Sweet, glad they release the GIL :-P","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"2113ce9d12ed46b54fe507f7c213aa3c43aa258a","unresolved":false,"context_lines":[{"line_number":213,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"* Crypto libraries (but they likely didn\u0027t work very well anyways) since these"},{"line_number":216,"context_line":"  are compute expensive instead of I/O expensive."},{"line_number":217,"context_line":"* All those libraries that forgot to think about threads (and are racey and/or"},{"line_number":218,"context_line":"  broken due to this)."},{"line_number":219,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_7679792e","line":216,"updated":"2015-02-18 00:25:01.000000000","message":"Which library? If they release the GIL, your program will be faster.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"b3bff734704a7e567982db6e763a763a9a27fd07","unresolved":false,"context_lines":[{"line_number":213,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"* Crypto libraries (but they likely didn\u0027t work very well anyways) since these"},{"line_number":216,"context_line":"  are compute expensive instead of I/O expensive."},{"line_number":217,"context_line":"* All those libraries that forgot to think about threads (and are racey and/or"},{"line_number":218,"context_line":"  broken due to this)."},{"line_number":219,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_e73cd195","line":216,"in_reply_to":"da86d52c_7679792e","updated":"2015-02-18 01:27:59.000000000","message":"This was more of just a guess. If there aren\u0027t any, thats cool too.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"4bb70603fbcd448db54271d6bfcfdad40c062130","unresolved":false,"context_lines":[{"line_number":213,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"* Crypto libraries (but they likely didn\u0027t work very well anyways) since these"},{"line_number":216,"context_line":"  are compute expensive instead of I/O expensive."},{"line_number":217,"context_line":"* All those libraries that forgot to think about threads (and are racey and/or"},{"line_number":218,"context_line":"  broken due to this)."},{"line_number":219,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_b4e3cd03","line":216,"in_reply_to":"da86d52c_e6892970","updated":"2015-02-18 15:44:17.000000000","message":"Will use that, thx :-P","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"fa5dfbdfdc629080a89bd11cd71298b01147089c","unresolved":false,"context_lines":[{"line_number":213,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"* Crypto libraries (but they likely didn\u0027t work very well anyways) since these"},{"line_number":216,"context_line":"  are compute expensive instead of I/O expensive."},{"line_number":217,"context_line":"* All those libraries that forgot to think about threads (and are racey and/or"},{"line_number":218,"context_line":"  broken due to this)."},{"line_number":219,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_e6892970","line":216,"in_reply_to":"da86d52c_e73cd195","updated":"2015-02-18 09:30:28.000000000","message":"IMO you should find another example. For example, the hashlib doesn\u0027t release the GIL in Python 2.6 and hashlib is CPU-bound.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"2113ce9d12ed46b54fe507f7c213aa3c43aa258a","unresolved":false,"context_lines":[{"line_number":215,"context_line":"* Crypto libraries (but they likely didn\u0027t work very well anyways) since these"},{"line_number":216,"context_line":"  are compute expensive instead of I/O expensive."},{"line_number":217,"context_line":"* All those libraries that forgot to think about threads (and are racey and/or"},{"line_number":218,"context_line":"  broken due to this)."},{"line_number":219,"context_line":""},{"line_number":220,"context_line":"Other deployer impact"},{"line_number":221,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_bb2bdae9","line":218,"updated":"2015-02-18 00:25:01.000000000","message":"Agreed. And it may be a pain to identify bugs and then to fix them.\n\n--\n\nSome Python modules of the standard library are still not fully thread safe yet :-( Examples of fixed issues: fnmatch, subprocess.Popen.wait, os.makedirs(), select.poll, etc.\n- http://bugs.python.org/issue23191\n- http://bugs.python.org/issue21291\n- http://bugs.python.org/issue21082\n- http://bugs.python.org/issue8865\n\nThere are probably corner cases which may not occur in practice. Unlikely, Murphy\u0027s Law is more and more true in my experience. Race conditions are rare on unit tests and more likely on production, probably because race conditions are more likely with high system load, whereas the execution of unit tests is usually sequential.\n\nUsing asyncio, you can choose to explicitly run a specific function in a thread. So you have a finer control how which modules must be thread safe. If I understand correctly the spec, all modules must be thread safe, otherwise a single bug will occur.\n\n--\n\nOther complex issues when using threads:\n\n* signals\n* fork()\n* subprocesses (combine signals+fork issues...)\n\nFor example, the whole subprocess module is not thread-safe in Python 2.7:\n- http://bugs.python.org/issue19809\n\nA common issue is to inherit an unwanted file descriptor. For example, thread A creates a pipe, spawn a child process with the the pipe; while the thread B creates a child process. The child process of the thread B inherits the file descriptor. Even if you use subprocess with close_fds\u003dTrue, a C library may spawn a child process without closing file descriptors. I had this issue on production with libguestfs :-( Hopefully, the issue was already fixed upstream (I just had to backport the fix).\n\nsubprocess issues with threads have been fixed step by step in each Python 3 release. The subprocess module has no more known race conditions related to threads in Python 3.4! For example, the PEP 446 implemented in Python 3.4 fixes the inheritance of file descriptors. Sorry, I don\u0027t want to open the \"Python 3\" can of worms! It\u0027s just a reminder that race conditions exist and are more common than what you can expect.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"fa5dfbdfdc629080a89bd11cd71298b01147089c","unresolved":false,"context_lines":[{"line_number":215,"context_line":"* Crypto libraries (but they likely didn\u0027t work very well anyways) since these"},{"line_number":216,"context_line":"  are compute expensive instead of I/O expensive."},{"line_number":217,"context_line":"* All those libraries that forgot to think about threads (and are racey and/or"},{"line_number":218,"context_line":"  broken due to this)."},{"line_number":219,"context_line":""},{"line_number":220,"context_line":"Other deployer impact"},{"line_number":221,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_c6ba650a","line":218,"in_reply_to":"da86d52c_6748e12d","updated":"2015-02-18 09:30:28.000000000","message":"The fix can be as simple as \"upgrade to the latest version\". But it may not be as simple as you expect.\n\n\"Random\" example: try to upgrade OpenStack from Python 2 to Python 3 to get subprocess fixes :-D (Oh OpenStack doesn\u0027t support Python 3 in 2015? Too bad.)\n\nOperating systems may use old versions of C libraries (libguestfs?) which are not yet thread-safe :-(","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"b3bff734704a7e567982db6e763a763a9a27fd07","unresolved":false,"context_lines":[{"line_number":215,"context_line":"* Crypto libraries (but they likely didn\u0027t work very well anyways) since these"},{"line_number":216,"context_line":"  are compute expensive instead of I/O expensive."},{"line_number":217,"context_line":"* All those libraries that forgot to think about threads (and are racey and/or"},{"line_number":218,"context_line":"  broken due to this)."},{"line_number":219,"context_line":""},{"line_number":220,"context_line":"Other deployer impact"},{"line_number":221,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_6748e12d","line":218,"in_reply_to":"da86d52c_bb2bdae9","updated":"2015-02-18 01:27:59.000000000","message":"Sounds like someone should fix these, haha.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"d17309edcec031a568939476b38bd81be04fa24b","unresolved":false,"context_lines":[{"line_number":215,"context_line":"* Crypto libraries (but they likely didn\u0027t work very well anyways) since these"},{"line_number":216,"context_line":"  are compute expensive instead of I/O expensive."},{"line_number":217,"context_line":"* All those libraries that forgot to think about threads (and are racey and/or"},{"line_number":218,"context_line":"  broken due to this)."},{"line_number":219,"context_line":""},{"line_number":220,"context_line":"Other deployer impact"},{"line_number":221,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_f715473d","line":218,"in_reply_to":"da86d52c_c6ba650a","updated":"2015-02-18 15:54:48.000000000","message":":) Some of openstack supports python 3.x (except for all those damn applications that don\u0027t, haha); point taken though :)","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"2113ce9d12ed46b54fe507f7c213aa3c43aa258a","unresolved":false,"context_lines":[{"line_number":229,"context_line":"code that is blocking is running (if it\u0027s running in one of these per-request"},{"line_number":230,"context_line":"threads that most openstack applications use, then they likely don\u0027t need to"},{"line_number":231,"context_line":"care). They may need to think about locks on shared data (especially anything"},{"line_number":232,"context_line":"regarding global data/state); although most projects are already avoiding this"},{"line_number":233,"context_line":"kind of usage already (by using ``context`` variables for per-request state"},{"line_number":234,"context_line":"for example); certain things like ``oslo.config`` objects may need to be"},{"line_number":235,"context_line":"analyzed to determine thread-safety but most other usages should not be"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_961c2dc4","line":232,"updated":"2015-02-18 00:25:01.000000000","message":"Hum, it\u0027s not conditional. You must care of thread-safety when accessing \"shared\" data. It\u0027s not always easy to guess if data is shared or not. You have to be *more* careful with threads than with eventlet, because a thread can be interrupted anywhere, not only on I/O (or explicitly).\n\neventlet, asyncio and threads are all complex :-( In term of the risk of introducing the bug, I would sort them like that: asyncio (less risk), eventlet, threads (more risk).\n\nThreads are many advantages, but we must be aware that writing thread-safe code is more difficult.\n\nI\u0027m not sure that all OpenStack have skills to take care of thread safety :-(","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"4bb70603fbcd448db54271d6bfcfdad40c062130","unresolved":false,"context_lines":[{"line_number":229,"context_line":"code that is blocking is running (if it\u0027s running in one of these per-request"},{"line_number":230,"context_line":"threads that most openstack applications use, then they likely don\u0027t need to"},{"line_number":231,"context_line":"care). They may need to think about locks on shared data (especially anything"},{"line_number":232,"context_line":"regarding global data/state); although most projects are already avoiding this"},{"line_number":233,"context_line":"kind of usage already (by using ``context`` variables for per-request state"},{"line_number":234,"context_line":"for example); certain things like ``oslo.config`` objects may need to be"},{"line_number":235,"context_line":"analyzed to determine thread-safety but most other usages should not be"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_947b2928","line":232,"in_reply_to":"da86d52c_6628d933","updated":"2015-02-18 15:44:17.000000000","message":"Sounds good. I look forward to seeing how it works out :)","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"b3bff734704a7e567982db6e763a763a9a27fd07","unresolved":false,"context_lines":[{"line_number":229,"context_line":"code that is blocking is running (if it\u0027s running in one of these per-request"},{"line_number":230,"context_line":"threads that most openstack applications use, then they likely don\u0027t need to"},{"line_number":231,"context_line":"care). They may need to think about locks on shared data (especially anything"},{"line_number":232,"context_line":"regarding global data/state); although most projects are already avoiding this"},{"line_number":233,"context_line":"kind of usage already (by using ``context`` variables for per-request state"},{"line_number":234,"context_line":"for example); certain things like ``oslo.config`` objects may need to be"},{"line_number":235,"context_line":"analyzed to determine thread-safety but most other usages should not be"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_a76579b0","line":232,"in_reply_to":"da86d52c_961c2dc4","updated":"2015-02-18 01:27:59.000000000","message":"If its hard to guess if data is shared, then IMHO people have written some really crappy code and/or they need to fix that.\n\nAs for risk-analysis, idk which is more complex and its hard to rank them. Knowing the amount of change this requires vs changing all the code to use asyncio and/or trilliuos the \u0027depth\u0027 of work for this is smaller I think; all the paths though will have issues, but nothing is ever easy ;)\n\nAs for openstack skills and threading, I don\u0027t know if I can judge people on that, not everyone is great at things, and likely some people won\u0027t get it, but it seems somewhat unfair to say that it can\u0027t be done (or that in general people lack the skills). People are just people and some will and some won\u0027t. That\u0027s life.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"fa5dfbdfdc629080a89bd11cd71298b01147089c","unresolved":false,"context_lines":[{"line_number":229,"context_line":"code that is blocking is running (if it\u0027s running in one of these per-request"},{"line_number":230,"context_line":"threads that most openstack applications use, then they likely don\u0027t need to"},{"line_number":231,"context_line":"care). They may need to think about locks on shared data (especially anything"},{"line_number":232,"context_line":"regarding global data/state); although most projects are already avoiding this"},{"line_number":233,"context_line":"kind of usage already (by using ``context`` variables for per-request state"},{"line_number":234,"context_line":"for example); certain things like ``oslo.config`` objects may need to be"},{"line_number":235,"context_line":"analyzed to determine thread-safety but most other usages should not be"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_6628d933","line":232,"in_reply_to":"da86d52c_a76579b0","updated":"2015-02-18 09:30:28.000000000","message":"\"Knowing the amount of change this requires vs changing all the code to use asyncio and/or trilliuos the \u0027depth\u0027 of work for this is smaller I think\"\n\nThis is just wrong. asyncio doesn\u0027t require to \"change all the code\". Changes are smaller than what you expect. I will port Ceilometer to asyncio to have numbers (size of the patch), instead of promises which doesn\u0027t look to be trusted at this point (I can understand that).","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":9107,"name":"Victor Stinner","email":"vstinner@redhat.com","username":"haypo"},"change_message_id":"2113ce9d12ed46b54fe507f7c213aa3c43aa258a","unresolved":false,"context_lines":[{"line_number":255,"context_line":"Using this section to highlight things we need to decide that aren\u0027t"},{"line_number":256,"context_line":"settled as of yet."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"* The whole spec listed above seems unsettled (but thats the point) ;)"},{"line_number":259,"context_line":""},{"line_number":260,"context_line":"Dependencies"},{"line_number":261,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_566d5531","line":258,"updated":"2015-02-18 00:25:01.000000000","message":"The transition plan between \"eventlet+monkey-patching\" to \"drop completly eventlet, no more monkey-patching\" is unclear to me. Can you maybe elaborate?","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"b3bff734704a7e567982db6e763a763a9a27fd07","unresolved":false,"context_lines":[{"line_number":255,"context_line":"Using this section to highlight things we need to decide that aren\u0027t"},{"line_number":256,"context_line":"settled as of yet."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"* The whole spec listed above seems unsettled (but thats the point) ;)"},{"line_number":259,"context_line":""},{"line_number":260,"context_line":"Dependencies"},{"line_number":261,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_c7050dc3","line":258,"in_reply_to":"da86d52c_566d5531","updated":"2015-02-18 01:27:59.000000000","message":"Sure; will file in more ideas here.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"bfa0e5b60971ff1f3514a9069e8877dcacc8f10a","unresolved":false,"context_lines":[{"line_number":274,"context_line":"References"},{"line_number":275,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":276,"context_line":""},{"line_number":277,"context_line":".. _tooz: https://github.com/openstack/tooz"},{"line_number":278,"context_line":".. _backport: https://pypi.python.org/pypi/futures"},{"line_number":279,"context_line":".. _TaskFlow: https://github.com/openstack/taskflow"},{"line_number":280,"context_line":".. _heapq: https://docs.python.org/2/library/heapq.html"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_e3a6640e","line":277,"updated":"2015-02-18 17:30:28.000000000","message":"These won\u0027t be rendered as links here, so the \"References\" section will appear to be empty. It\u0027s a style issue, I guess, but the idea with adding this section was to list external references here instead of linking throughout the document.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"bd525db6fac55b13cd70eae322bc4ec7e566bdb4","unresolved":false,"context_lines":[{"line_number":274,"context_line":"References"},{"line_number":275,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":276,"context_line":""},{"line_number":277,"context_line":".. _tooz: https://github.com/openstack/tooz"},{"line_number":278,"context_line":".. _backport: https://pypi.python.org/pypi/futures"},{"line_number":279,"context_line":".. _TaskFlow: https://github.com/openstack/taskflow"},{"line_number":280,"context_line":".. _heapq: https://docs.python.org/2/library/heapq.html"}],"source_content_type":"text/x-rst","patch_set":10,"id":"da86d52c_9d042116","line":277,"in_reply_to":"da86d52c_e3a6640e","updated":"2015-02-18 19:37:50.000000000","message":"Oh, hmmmm, ok dokie then.","commit_id":"16aa20e88fcb8e923016673a5aab69d046d5449a"}]}