-
-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New version online #15
Comments
It would be cool to be able to specify certain threads as OK to hang, I have some threads that intentionally block for a while |
Ignoring certain threads is what I've already started to work on! :) But
I'm still not sure what is the best way to do this. I'm going to do more
experiments.
чт, 19 янв 2017 г., 7:11 coffenbacher <[email protected]>:
… It would be cool to be able to specify certain threads as OK to hang, I
have some threads that intentionally block for a while
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AANwwDZqlkUnz79_c82alBLwrfAIrkuKks5rTtRvgaJpZM4LVNdJ>
.
|
I ask myself the question: How would I like to use it?
This comes into my mind:
t = Thread(...)
hanging_threads.ignore(t)
hanging_threads.ignore(t.name)
or
def thread():
hanging_threads.ignore()
What are your thoughts?
…On 19.01.2017 05:22, Artem Rizhov wrote:
Ignoring certain threads is what I've already started to work on! :) But
I'm still not sure what is the best way to do this. I'm going to do more
experiments.
чт, 19 янв 2017 г., 7:11 coffenbacher ***@***.***>:
> It would be cool to be able to specify certain threads as OK to hang, I
> have some threads that intentionally block for a while
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
>
<#15 (comment)>,
> or mute the thread
>
<https://github.com/notifications/unsubscribe-auth/AANwwDZqlkUnz79_c82alBLwrfAIrkuKks5rTtRvgaJpZM4LVNdJ>
> .
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAieIEbavmeWgKeqIHV7Pr3FExKWi3L-ks5rTuUZgaJpZM4LVNdJ>.
|
Looks good. Actually I'm not sure how to do exactly what I want, because
some of the threads I want to ignore are spawned by packages I'm using... I
haven't looked into how to get pointers to them.
On Thu, Jan 19, 2017 at 7:15 AM, Nicco Kunzmann <[email protected]>
wrote:
… I ask myself the question: How would I like to use it?
This comes into my mind:
t = Thread(...)
hanging_threads.ignore(t)
hanging_threads.ignore(t.name)
or
def thread():
hanging_threads.ignore()
What are your thoughts?
On 19.01.2017 05:22, Artem Rizhov wrote:
> Ignoring certain threads is what I've already started to work on! :) But
> I'm still not sure what is the best way to do this. I'm going to do more
> experiments.
>
> чт, 19 янв 2017 г., 7:11 coffenbacher ***@***.***>:
>
> > It would be cool to be able to specify certain threads as OK to hang, I
> > have some threads that intentionally block for a while
> >
> > —
> > You are receiving this because you are subscribed to this thread.
> > Reply to this email directly, view it on GitHub
> >
> <https://github.com/niccokunzmann/hanging_threads/
issues/15#issuecomment-273670653>,
> > or mute the thread
> >
> <https://github.com/notifications/unsubscribe-auth/AANwwDZqlkUnz79_
c82alBLwrfAIrkuKks5rTtRvgaJpZM4LVNdJ>
> > .
> >
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/niccokunzmann/hanging_threads/
issues/15#issuecomment-273678769>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/
AAieIEbavmeWgKeqIHV7Pr3FExKWi3L-ks5rTuUZgaJpZM4LVNdJ>.
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAPAa1xzRdYxf651Julh06lzzxrGni39ks5rT34hgaJpZM4LVNdJ>
.
|
The problem is that such threads may be started automatically by
third-party modules. For example Django starts two threads for development
server. I'm trying to ignore the first started threads using timeout, but
this solution looks a bit hacky, and I'm not sure I really want to ignore
those threads forever because they also potentially may hang.
|
Without looking into how it should be implemented: How would you like to use it?
How to use it is the first step: Specification first. If you can write an empty function with a good documentation, we can find a way to (test and) implement. Threads are started by functions. They have code objects. There is a lot of information available. The question is: What behavior/interface would you like assuming all is possible. - I like to divide what and how. |
Maybe we should ask ourself what problem we want to solve? Why we want to
ignore some threads?
… |
Great point. My problem is that I start ~10 threads, each of which may
hang. However, those threads use libraries that spawn other threads
that *intentionally
*hang on time.sleep. So, perhaps a better solution for my scenario is not
ignoring threads but rather a whitelist of hang locations.
…On Thu, Jan 19, 2017 at 7:36 AM, Artem Rizhov ***@***.***> wrote:
Maybe we should ask ourself what problem we want to solve? Why we want to
ignore some threads?
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAPAa_NFVbggZsS_V4LwwgsBLIm0Skyzks5rT4MYgaJpZM4LVNdJ>
.
|
Ok, so let them hang. This is not real problem because this is expected behaviour. What is the real problem with these sleeping threads? I mean, we should think why we are bothering about this at all. |
Right, the sleeping threads are fine. It is the other threads that hang
unintentionally that are the problem, and unfortunately the error messages
from the sleeping threads swamp any information from the other ones.
I think a whitelist of files / lines to ignore would be sufficient for my
scenario. I'm not sure about other scenarios.
On Jan 19, 2017 9:02 AM, "Artem Rizhov" <[email protected]> wrote:
However, those threads use libraries that spawn other threads that
*intentionally* hang on time.sleep
Ok, so let them hang. This is not real problem because this is expected
behaviour. What is the real problem with these sleeping threads? I mean, we
should think why we are bothering about this at all.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAPAaxkwM-fQq7YVyHV6pY9hIF6lPqiXks5rT5cGgaJpZM4LVNdJ>
.
|
How would you like to specify such a hang location?
start_monitoring(condition=lambda stack:
stack.starts_in_module(__name__))
to only monitor threads from in the module or
start_monitoring(condition=lambda stack: not
stack.has_call_to(time.sleep))
to not monitor time.sleep() ?
Which interface expresses most clearly what you would like to achieve?
What are your ideas?
…On 19.01.2017 17:10, coffenbacher wrote:
Great point. My problem is that I start ~10 threads, each of which may
hang. However, those threads use libraries that spawn other threads
that *intentionally
*hang on time.sleep. So, perhaps a better solution for my scenario is not
ignoring threads but rather a whitelist of hang locations.
On Thu, Jan 19, 2017 at 7:36 AM, Artem Rizhov ***@***.***>
wrote:
> Maybe we should ask ourself what problem we want to solve? Why we
want to
> ignore some threads?
>
>
> >
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
>
<#15 (comment)>,
> or mute the thread
>
<https://github.com/notifications/unsubscribe-auth/AAPAa_NFVbggZsS_V4LwwgsBLIm0Skyzks5rT4MYgaJpZM4LVNdJ>
> .
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAieIOYmiIHG8vuHPSoRvLKo7ps8F1seks5rT4sLgaJpZM4LVNdJ>.
|
Good idea, maybe allow the user to pass a function / lambda that returns a
boolean based on whether the hang should be ignored.
Like this pseudocode (sorry on mobile, also don't exactly know what the
argument to the function would contain but something like this
def ignore(stack):
if 'time.sleep' in str(stack.current_line):
return True
hanging_threads.start_monitoring(whitelist_func=ignore)
…On Jan 19, 2017 11:07 AM, "Nicco Kunzmann" ***@***.***> wrote:
How would you like to specify such a hang location?
start_monitoring(condition=lambda stack:
stack.starts_in_module(__name__))
to only monitor threads from in the module or
start_monitoring(condition=lambda stack: not
stack.has_call_to(time.sleep))
to not monitor time.sleep() ?
Which interface expresses most clearly what you would like to achieve?
What are your ideas?
On 19.01.2017 17:10, coffenbacher wrote:
> Great point. My problem is that I start ~10 threads, each of which may
> hang. However, those threads use libraries that spawn other threads
> that *intentionally
> *hang on time.sleep. So, perhaps a better solution for my scenario is not
> ignoring threads but rather a whitelist of hang locations.
>
> On Thu, Jan 19, 2017 at 7:36 AM, Artem Rizhov ***@***.***>
> wrote:
>
> > Maybe we should ask ourself what problem we want to solve? Why we
> want to
> > ignore some threads?
> >
> >
> > >
> >
> > —
> > You are receiving this because you commented.
> > Reply to this email directly, view it on GitHub
> >
> <https://github.com/niccokunzmann/hanging_threads/
issues/15#issuecomment-273808469>,
> > or mute the thread
> >
> <https://github.com/notifications/unsubscribe-auth/AAPAa_NFVbggZsS_
V4LwwgsBLIm0Skyzks5rT4MYgaJpZM4LVNdJ>
> > .
> >
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/niccokunzmann/hanging_threads/
issues/15#issuecomment-273818931>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/
AAieIOYmiIHG8vuHPSoRvLKo7ps8F1seks5rT4sLgaJpZM4LVNdJ>.
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAPAa0t3nPbklObGPIFSyBgJYkWY-ppgks5rT7SDgaJpZM4LVNdJ>
.
|
So, this is the real problem, I guess. Maybe we can just get rid of this swamping messages? My propositions:
|
Sure, those options would work for me as well
…On Jan 19, 2017 12:46 PM, "Artem Rizhov" ***@***.***> wrote:
the error messages from the sleeping threads swamp any information from
the other ones.
So, this is a real problem, I guess. Maybe we can just get rid of this
swamping messages?
My propositions:
1. Rewrite the logging algorithm so that it reports once when a thread
hands, and then reports once again when the thread awakes. This is done
already in my branch, I just have to cleanup things and create a PR.
2. Add an option to ignore repeating hangs, so if a thread hangs on
certain line and then awakes, then hanging on this line will not be
considered as hangs anymore.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAPAaxquZZS7uXUP_2phgd6lBWRRkJwcks5rT8uagaJpZM4LVNdJ>
.
|
Ok, I'll prepare PR for the first part (which seems reasonable in any case), and then we will be able to implement the second one, if everybody agree. @niccokunzmann what do you think about this? |
@coffenbacher It also may be useful to add an option to ignore threads that hangs on |
Sure, please go ahead. |
@coffenbacher Would you like to create a pull-request with the documentation for the functionality which you would like to use? |
If there are a lot of prints, it could be good to have an option to ignore time.sleep in the future. |
There is a new version online: 1.0.0
What should be in the next version?
The text was updated successfully, but these errors were encountered: