hberaud[m] | zigo: o/ I think we have a potential fix https://github.com/eventlet/eventlet/pull/1042, but for now we need further investigation to confirm that it fix or not the problem you nova bug you shared with us. | 13:50 |
---|---|---|
zigo | hberaud[m]: Hi! I thought you were on PTO ! :) | 13:50 |
hberaud[m] | I came back this morning :) | 13:51 |
zigo | Ah, cool ! :) | 13:51 |
zigo | I can test that patch in my virtualized env. | 13:51 |
zigo | Got Trixie + Epoxy up and running. | 13:51 |
hberaud[m] | that would be awesome | 13:51 |
zigo | Just give me a few minutes ! :) | 13:52 |
hberaud[m] | please feel free to join the conversation directly on the pull request | 13:52 |
hberaud[m] | sure | 13:52 |
zigo | I honestly don't have the skills to help. :/ | 13:52 |
hberaud[m] | well just sharing your observation is already helping us :) | 13:53 |
hberaud[m] | but if you prefer I can be the proxy between this openstack discussion and the eventlet PR discussion | 13:54 |
zigo | I can report what I see in the PR, no problem. | 13:55 |
hberaud[m] | thanks, much appreciated | 13:55 |
zigo | Nope, same issue: | 13:56 |
zigo | AttributeError: 'SessionClient' object has no attribute 'endpoint_override' | 13:56 |
hberaud[m] | ack thanks | 13:56 |
zigo | Please try another magic spell ! :) | 13:57 |
zigo | Is all the brokenness in eventlet/patcher.py ? | 13:58 |
zigo | Since gc.disable() kind of "fix" things, would it be possible to just do that, and then re-enable the gc when the thread is finished? | 14:00 |
zigo | I know that would be a *very* ugly hack, but at this point ... :P | 14:00 |
zigo | hberaud[m]: ^ | 14:00 |
zigo | Where's the piece of code that re-implement threads? | 14:01 |
zigo | This, I guess? | 14:02 |
zigo | ./eventlet/green/thread.py | 14:02 |
zigo | ./eventlet/green/threading.py | 14:02 |
zigo | ./eventlet/greenthread.py | 14:02 |
hberaud[m] | Well, I'm not enoughly expert of the eventlet patcher to answer that question now, my co-maintainer Itamar is far more skilled with that RLock/Patch module than me, I can try to initiate a discussion with him and see what would be feasible or not | 14:03 |
hberaud[m] | ./eventlet/green/thread.py | 14:03 |
hberaud[m] | is for https://docs.python.org/fr/3/library/_thread.html#module-_thread | 14:04 |
hberaud[m] | threading is for https://docs.python.org/fr/3/library/threading.html | 14:04 |
zigo | Cool, c'est en Français ! :) | 14:04 |
hberaud[m] | ooops lol | 14:05 |
zigo | Nan, ça me va ! :) | 14:05 |
hberaud[m] | translation included! | 14:05 |
hberaud[m] | and greenthreads for patching greenlet things | 14:06 |
zigo | Ok, so we have __spawn_green() that does the thread start, is there somewhere executed when the thread stops?!? | 14:07 |
zigo | (I guess you see where I'm going... :P) | 14:07 |
hberaud[m] | :) | 14:07 |
hberaud[m] | good question let me check the code | 14:07 |
hberaud[m] | At the thread level we have an "exit" method https://github.com/eventlet/eventlet/blob/master/eventlet/green/thread.py#L144 , but apparently nothing about "cancel" or "stop" or around an event triggered at stopping. At the threading level we have a greenthread join https://github.com/eventlet/eventlet/blob/master/eventlet/green/threading.py#L42. This green thread class expose thread-like attributes and methods | 14:15 |
hberaud[m] | concerning eventlet/greenthread this module is a glue between greenlet and the Eventlet representation of the python threading (threading and _tread from the stdlib) | 14:20 |
hberaud[m] | this module implement additional methods like kill and cancel | 14:23 |
hberaud[m] | but we should seen this module more with a greenlet coroutine nature than with a native thread nature | 14:24 |
zigo | ok | 14:24 |
hberaud[m] | IMO if we have to implement some changes, then they should be either at the eventlet/green/thread*.py level or at the eventlet/patcher.py level | 14:27 |
JayF | zigo: IDK how to fix the issue; but gc.disable() would essentially lead to unbound memory growth for the process | 14:43 |
zigo | JayF: I'm aware, I even saw it happening. :) | 17:58 |
JayF | I honestly assumed so, but I try not to leave things unsaid unless I'm 100% sure :D | 17:58 |
zigo | hberaud[m]: Do you think sean's suggestion to use EVENTLET_HUB=asyncio could work? | 17:59 |
JayF | Even if it works, it might not be wise to do that in a package for lots of use cases, given we don't CI openstack against that configuration and it's the type of change which might be subtly breaky | 18:00 |
hberaud[m] | zigo: where have you seen such suggestion? | 18:55 |
hberaud[m] | I need more context to properly understand that claim | 18:56 |
zigo | Gosh... I remember talking with Jay Pipe in 2014 about eventlet, I can even now remember hearing him saying "die eventlet die..." ... | 19:03 |
zigo | hberaud[m]: In the list, in the thread I initially opened with [designate] | 19:04 |
hberaud[m] | Well, the asyncio hub was created in January 2024 https://github.com/eventlet/eventlet/pull/870 | 19:06 |
hberaud[m] | at first glance I'm not sure to see how it could help to solve such kind of issues | 19:09 |
hberaud[m] | if the compatibility of patcher still remains poorly aligned with Python 3.13+, I do not see how switching to an other hub could help, the logic behind the patcher and behind the patched stdlib module would more or less remains the same. | 19:11 |
zigo | Ok, I'll try anyways, though right now, I'm going out. Have a nice week-end! | 19:16 |
hberaud[m] | and if I'm right the syncrhonicity primitives are not same between threads and coroutines. Concerning the garbage collector, it is global, objects are collected in a global manner for the running process, no matters their type (not limited by thread or event loop) | 19:18 |
hberaud[m] | I'm going to eject too, have a nice week end | 19:19 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!