This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: context[2] stuck: (null)


In the "probe begin" I can offload the init to a just spawned thread
and return from the "probe begin" immediately. The rest of the probes
will test a global atomic and exit if the data structures are not
ready yet.

In the "probe end" I have another problem. I have to wait for the
offloaded task to complete. I am polling an atomic in a tight loop.
This is not quite a solution I like.

On Wed, Jul 12, 2017 at 6:39 PM, Arkady <arkady.miasnikov@gmail.com> wrote:
> On Wed, Jul 12, 2017 at 5:40 PM, Arkady <arkady.miasnikov@gmail.com> wrote:
>> On Wed, Jul 12, 2017 at 4:55 PM, David Smith <dsmith@redhat.com> wrote:
>>> On Wed, Jul 12, 2017 at 8:16 AM, Arkady <arkady.miasnikov@gmail.com> wrote:
>>>> My goal is to allocate the shared memory - one or more large (100s of
>>>> MBs) vzallocs,
>>>> add a dozen files to the sysfs and debugfs.
>>>
>>> Note that systemtap already has procfs 'probes', which create procfs files.
>>>
>>
>> procfs API has limitations and inconveniences.
>>
>>> If we wanted to include this functionality with systemtap, we'd have
>>> to generalize this a bit and make it less domain specific. Can you
>>> think of a script language extension that would express what you are
>>> trying to do here?
>>>
>>
>> I would like to have an Initialization probe which allows use of blocking APIs.
>
> .... for example probe begin_interruptable {}  and probe end_interruptable {}
>
>>
>>> --
>>> David Smith
>>> Principal Software Engineer
>>> Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]