Re: Profiler showing path dependency?
Go Luhng wrote at 2020-3-13 18:51 -0400: >Consider a simple call graph: `main()` calls `foo()`, which calls >`bar()`. Then `main()` calls `qux()` which also calls `bar()`, but >with different parameters. > >When you run the above through cProfile and view the result in >SnakeViz, you will see `main()` calling `foo()` and `qux()`, with each >of them calling `bar()`. However, if you hover or click on `bar()`, >you will see the global aggregate statistics for it. For example, the >number of times it has been called, and their total time cost. > >Is there a way to get a path-dependent profiler breakdown for `bar()`? Again (like for profiling with parameters), you have the problem of mass data: in typical situations, you have a huge number of different call paths. I have not yet used "cProfile" but "profile" and its extension "dm.profile". "profile" collects statistics based on function and caller/callee. This means, that you can derived limited information about the call paths: the immediate caller/callees, but not the complete call paths. Again, you would (almost surely) need to write your own profiler to gather information broken down on the complete call paths. Such a profiler could only be used in restricted situations (where the amount of call paths is quite limited). -- https://mail.python.org/mailman/listinfo/python-list
Re: Lock acquisition by the same thread - deadlock protection
On 12Mar2020 20:08, Dieter Maurer wrote: Yonatan wrote at 2020-3-11 16:24 +0200: That code I'm talking about didn't require a reentrant lock - the algorithm really wasn't reentrant. Let me clarify my point: I'm wondering why the non-reentrant lock doesn't raise an exception immediately on this erroneous situation. I thought it could be altered, or at least we could add an option to let a `threading.Lock` behave like a pthread mutex in mode `PTHREAD_MUTEX_ERRORCHECK`: Disallow double locking by same thread, disallow unlocking by another thread. The documentation for the basic lock explicitely allows lock release by a foreign thread. As I understand the documentation, this lock type is by design very basic - a mechanism to implement higher level abstractions. I use other synchronisation mechanisms when the basic lock does not fit my requirements. Aye. I have certainly gone: - take lock associated with some task specific resource - set up task - kick off worker Thread (or queue worker function for later) - worker releases the lock However, having an error check mode disallowing attempts by the same Thread to take a Lock it itself took seems valuable. If the lock object has that piece of information (IIRC it does). Cheers, Cameron Simpson (formerly c...@zip.com.au) -- https://mail.python.org/mailman/listinfo/python-list
