From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44753 invoked by alias); 14 Jul 2017 13:44:30 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 44682 invoked by uid 89); 14 Jul 2017 13:44:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=Hx-spam-relays-external:74.125.82.67, H*RU:74.125.82.67, inconveniences X-HELO: mail-wm0-f67.google.com Received: from mail-wm0-f67.google.com (HELO mail-wm0-f67.google.com) (74.125.82.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 14 Jul 2017 13:44:22 +0000 Received: by mail-wm0-f67.google.com with SMTP id j85so10907651wmj.0 for ; Fri, 14 Jul 2017 06:44:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=w7elWBUT+nuihxrLp27WV1F99c5f7GHOfnlj5DASKd8=; b=b4vM4YGFdw2dWneHKBczIa8+jHdk449l5+w60r5uEvqcfGDEJhL5hi7pZ/xtyQPegX BkPUfM8P53ydW9/dggOZguB7lnPwh7PK/hnCP5xskTGfjqziMQYBeWc6lKPvgme4rnI/ aHGiK/ExCTKND27vKClkBio1yRQUVhARBp0G3m+KRTegr2IIUKXrAqq/uI7gsaCpXxWT qZUlrsgZiE9jL2SNMnP+D2EGGB1+ynpK+sAOx9TnTPgfFYxM26RdxvtP24KvNmQGY0j8 t8hESsd/8FJnjD0/fv5zX1o8tPRBz9uXwL3IDeBe3UtyT5+VeAkuWyKlmaOFNgG/Ef5w bPBA== X-Gm-Message-State: AIVw111SKXGaX0jIKVtuzJ1eWRdR3brBq8rbs7Ou5HbJMyBHgDahFLFP QGb26/Sdsj14kHP3VkD7YoQ6zlgERw== X-Received: by 10.80.174.38 with SMTP id c35mr6895813edd.129.1500039860850; Fri, 14 Jul 2017 06:44:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.182.8 with HTTP; Fri, 14 Jul 2017 06:44:00 -0700 (PDT) In-Reply-To: References: From: Arkady Date: Fri, 14 Jul 2017 13:44:00 -0000 Message-ID: Subject: Re: context[2] stuck: (null) To: David Smith Cc: systemtap@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-q3/txt/msg00040.txt.bz2 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 wrote: > On Wed, Jul 12, 2017 at 5:40 PM, Arkady wrote: >> On Wed, Jul 12, 2017 at 4:55 PM, David Smith wrote: >>> On Wed, Jul 12, 2017 at 8:16 AM, Arkady 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