Allow use of tachyon as imported python module

Ideas
1

Context: PEP-799 / tachyon.

I have a long-standing issue open on py-spy (a similar sampling profiler)’s issue tracker, that it would be useful to be able to use the profiler as a python library, and not just as a CLI interface. I thought, since tachyon is being introduced to the stdlib, I might add the idea here as well.

To summarize my use case:

  • Control plane application written in python, which launches the actual application processes
  • Each application process is therefore a child process of the controlplane
  • Devs can interact with the control plane and eg issue commands
  • I’d like to be able to issue a “profile this app instance please” command to the process
  • For security reasons, I don’t want to be running the controlplane as a sudoer, and I don’t want to allow any process to attach to another process. Therefore the call to attach must be issued by a parent process.

If tachyon could be invoked directly from within python code, that would mean it would be running under the control plane’s PID, allowing it to safely attach to launched application processes while still maintaining the principle of least access.

(There are also some other use cases discussed in the github issue).

Just a thought!

1 Like
2

You can already do this.

from profiling import sampling as samp
dir(samp)
['CollapsedStackCollector', 'Collector', 'GeckoCollector', 'HeatmapCollector', 'PstatsCollector', 'StringTable',
'__all__', '__builtins__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__path__',
'__spec__', '_css_utils', 'collector', 'constants', 'gecko_collector', 'heatmap_collector', 'opcode_utils',
'pstats_collector', 'stack_collector', 'string_table']

Look in samp.init to see where objects come from. Look in samp.cli to see how the cli uses the objects. No doc yet.

2 Likes
3

Oh brilliant! Then consider this just a request for docs :slight_smile:

Awesome. Seriously awesome. Keep up the good work and thanks for considering library usage!

3 Likes
4

Given the above, I have moved this from ideas to documentation, so that hopefully someone with available time and an interest in working on the documentation is more likely to see it.

1 Like
5

Unfortunately the reason that this is not documented is that we don’t plan to offer it as a library (yet). Our objective right now is to ensure everything works as good as possible and this forces us to change things around quite heavily based on feedback and things we discover. We will soon mark all modules as private (underscore prefixes).

I know this is a bummer but please understand that we need to prioritise not shooting ourselves in the foot too early and given how much we we changing things until we get it exactly right I know is the right choice.

Perhaps in 3.16 :slight_smile:

(Moving the post back to ideas)

2 Likes