From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30344 invoked by alias); 23 Sep 2005 19:44:04 -0000 Mailing-List: contact systemtap-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sources.redhat.com Received: (qmail 30278 invoked by uid 22791); 23 Sep 2005 19:43:52 -0000 Subject: Re: array sorting checked in From: Martin Hunt To: "Frank Ch. Eigler" Cc: systemtap@sources.redhat.com In-Reply-To: References: <1127464449.7927.10.camel@dragon> Content-Type: text/plain Organization: Red Hat Inc. Date: Fri, 23 Sep 2005 19:44:00 -0000 Message-Id: <1127504629.3196.32.camel@dragon> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-SW-Source: 2005-q3/txt/msg00577.txt.bz2 On Fri, 2005-09-23 at 13:57 -0400, Frank Ch. Eigler wrote: > hunt wrote: > > > [...] I checked in several new functions to the runtime. > > _stp_map_sort(MAP map, int keynum, int dir) [...] > > OK. It seems to me that the most straightforward way to expose this > in the language would be as a modifier for the "foreach" statement, > something like: > > foreach ([x,y] in sort(array)) { > do_something_with (array[x,y]) > if (i++ > 10) break > } > > > A related modifier could serve as an iteration count limiter, which > would presumably save sorting time. Given the implementation's likely > performance, it would be wise to penalize sorting by an extra > actioncount, to represent its cost. That seems to add unnecessary complexity to the language. I understand you are focusing on the locking issues but there must be a better solution. By far the most likely uses of array sorting are for printing (at probe exit) and printing at timed intervals (like top). In the second case locks are required. > Adding a plain "sort " operation would be of only limited > applicability, considering the possibility of concurrent/subsequent > modifications, invalidating the sorted property. > foreach should holds > a lock (but see bug #1275) on the array during iteration, which if > finagled properly, would protect the sorted property for the duration > of iteration. This seems a poor excuse. Lets keep our language as simple as possible. There are several other possibilities. Why not provide a way to pass array references, allowing us to extend the language without hardcoding the translator? Then we simply do something like function print_sorted_mapn (foo:array, num:long, key:long, dir:long, fmt:string) %{ LOCK(THIS->foo); _stp_map_sortn(THIS->foo, THIS->num, THIS->key, THIS->dir); _stp_map_printn(THIS->foo, THIS->num, THIS->fmt); UNLOCK(THIS->foo); %} or maybe make locks explicit in the systemtap language: lock(foo) { sort(foo) print(foo) }