From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29635 invoked by alias); 13 Sep 2010 02:21:04 -0000 Received: (qmail 29627 invoked by uid 22791); 13 Sep 2010 02:21:03 -0000 X-SWARE-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from relay.ihostexchange.net (HELO relay.ihostexchange.net) (66.46.182.57) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 13 Sep 2010 02:20:58 +0000 Received: from mailhost.internal (203.206.165.193) by smtp.ihostexchange.net (66.46.182.50) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 12 Sep 2010 22:20:53 -0400 Received: from [172.29.254.198] (unknown [172.29.254.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.internal (Postfix) with ESMTPSA id 06D0B30B00; Mon, 13 Sep 2010 12:18:46 +1000 (EST) Message-ID: <4C8D8A80.7010904@evostor.com> Date: Mon, 13 Sep 2010 02:21:00 -0000 From: Greg Banks User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ken McDonell CC: "Frank Ch. Eigler" , "systemtap@sources.redhat.com" , "pcp@oss.sgi.com" Subject: Re: [pcp] suitability of PCP for event tracing References: <20100827153906.GD3185@redhat.com> <4C7A7DFE.2040606@internode.on.net> <20100831194941.GC5762@redhat.com> <4C8D0317.6000807@internode.on.net> In-Reply-To: <4C8D0317.6000807@internode.on.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2010-q3/txt/msg00408.txt.bz2 Ken McDonell wrote: > Apologies for my tardiness in responding, but I'm travelling at the > moment (typing this on a train and then on a ferry somewhere in Norway). > > > Sounds like fun :) > > > On 3/09/2010 5:39 AM, Frank Ch. Eigler wrote: > >> ... >> >> OK, then it looks like we'd have at least a few separate pieces to >> work on: >> >> * extensions to the PMCD<->PMDA API/protocol to allow PMDAs to push >> event data, and corresponding extensions for PMclients<->PMCD >> > > I'd really like to see some more discussion on how people think this is > going to work. None of the PCP libraries are thread-safe (again a > deliberate design decision at the original point of conception), I've made a brief survey of the place in the libpcp code which are not threadsafe; there's *lots* of them but most are easily fixed without breaking external interfaces. I'd estimate a few weeks' work is involved. I'm interested in helping on this for my own reasons (I'd like kmchart to be more robust when communication with pmdas is disrupted). > and > asynchronous delivery of data from pmdas through pmcd to clients > increases the likelihood that people will want to use multiple threads > to handle PCP calls. There are some asynchronous calls that were > grafted onto libpcp later on, but these have very little use in existing > code and no QA coverage. > > They're also a right bugger to program with, as we've discovered. I would be happy to see them deprecated in favour of full libpcp thread safety. -- Greg.