From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Boris Zbarsky Newsgroups: gmane.lisp.guile.user Subject: Re: Issues using statprof (no samples taken) Date: Tue, 18 Nov 2008 11:15:50 -0500 Message-ID: <4922EA36.7080905@mit.edu> References: <491DBAE5.5060100@mit.edu> <87prkx28cp.fsf@gnu.org> <49206D71.9070407@mit.edu> <87bpwecrsb.fsf@gnu.org> <49218F97.2000805@mit.edu> <87abbybatj.fsf@gnu.org> <4921E796.6000408@mit.edu> <87wsf1iawe.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1227024994 2051 80.91.229.12 (18 Nov 2008 16:16:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Nov 2008 16:16:34 +0000 (UTC) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Nov 18 17:17:36 2008 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1L2TGh-0002aK-D5 for guile-user@m.gmane.org; Tue, 18 Nov 2008 17:17:35 +0100 Original-Received: from localhost ([127.0.0.1]:51975 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L2TFY-0005Vo-IW for guile-user@m.gmane.org; Tue, 18 Nov 2008 11:16:24 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L2TFB-0005SU-UF for guile-user@gnu.org; Tue, 18 Nov 2008 11:16:02 -0500 Original-Received: from [199.232.76.173] (port=50607 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L2TFA-0005Rn-UB for guile-user@gnu.org; Tue, 18 Nov 2008 11:16:01 -0500 Original-Received: from biscayne-one-station.mit.edu ([18.7.7.80]:49702) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L2TFB-0001Y4-8W for guile-user@gnu.org; Tue, 18 Nov 2008 11:16:01 -0500 Original-Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id mAIGFsBT024259 for ; Tue, 18 Nov 2008 11:15:54 -0500 (EST) Original-Received: from boris-zbarskys-macbook-pro.local (dsl092-065-154.bos1.dsl.speakeasy.net [66.92.65.154]) (authenticated bits=0) (User authenticated as bzbarsky@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id mAIGFowC001285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 18 Nov 2008 11:15:53 -0500 (EST) User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) In-Reply-To: <87wsf1iawe.fsf@gnu.org> X-Scanned-By: MIMEDefang 2.42 X-Spam-Score: 0.00 X-MIME-Autoconverted: from 8bit to quoted-printable by biscayne-one-station.mit.edu id mAIGFsBT024259 X-detected-operating-system: by monty-python.gnu.org: Solaris 9 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:6938 Archived-At: Ludovic Court=E8s wrote: >>> Maybe with `strace(1)' or similar? >> Unfortunately, that just shows the pointer to the struct, not the >> value in the struct itself.... >=20 > Under GNU/Linux it does the right thing. :-) Ah, cool. I'll dig up my Linux machine at some point to double-check=20 this if I exhaust all other possibilities. >> I tried adding that call to code that certainly runs repeatedly >> between statprof-start and statprof-stop (the code that handles >> updating the gnucash progress bar, in fact), but that doesn't seem to >> help. >=20 > Are you sure that piece of code is ever called? Absolutely. Adding display statements there prints stuff. > Is it called from an "idle" handler or some such? Not that I can tell. More precisely, the code now looks more or less=20 like this: (statprof-reset 0 500 #t) (statprof-start) (set! foo (map (lambda (bar) (body)) myList)) (statprof-stop) (statprof-display) where (body) includes the (select) calls you suggested. > Another idea is that you could try modifying `statprof' so that it uses >=20 > (setitimer ITIMER_REAL ...) >=20 > and >=20 > (sigaction SIGALRM profile-signal-handler) >=20 > just to see if it makes a difference... That doesn't seem to have any effect. Interestingly, if I change the=20 setitimer call but NOT the sigaction call I see the program terminate=20 with an uncaught SIGPROF... So clearly the sigaction is having _some_=20 effect. Just not that of calling the handler. ;) > It may be that they use a single pthread (the "main" thread), and that > they handle events and timeouts via a GTK+ even loop. Quite possible, yes. > Can you check with GDB whether `pthread_create(3)' is ever called? Yes, it is, with this stack: (gdb) where #0 0x91df0f80 in pthread_create () #1 0x016c5ac3 in g_thread_create_posix_impl () #2 0x01772f93 in g_thread_create_full () #3 0x0174686a in g_child_watch_source_init_multi_threaded () #4 0x01746a15 in g_child_watch_source_new () #5 0x01746a57 in g_child_watch_add_full () #6 0x01746b1f in g_child_watch_add () #7 0x003459f3 in gnc_spawn_process_async () #8 0x0033412b in _wrap_gnc_spawn_process_async () #9 0x0161a312 in scm_deval () #10 0x01616364 in scm_deval () #11 0x0161bc27 in scm_dapply () #12 0x01611ee7 in scm_apply () #13 0x01611c20 in scm_call_0 () #14 0x01602b2c in scm_dynamic_wind () #15 0x0161aa96 in scm_deval () #16 0x01615f6a in scm_deval () #17 0x01613727 in scm_i_eval_x () #18 0x016137fb in scm_primitive_eval_x () #19 0x01665cd6 in inner_eval_string () #20 0x0161de4d in scm_c_with_fluids () #21 0x0161dec6 in scm_c_with_fluid () #22 0x01637baf in scm_c_call_with_current_module () #23 0x01665d4a in scm_eval_string () #24 0x01665c5c in scm_c_eval_string () #25 0x00003961 in inner_main () #26 0x016331f9 in invoke_main_func () #27 0x016331a4 in scm_boot_guile_1 () #28 0x01632eb1 in scm_boot_guile () #29 0x000042a2 in main () That seems to be the only pthread_create call. Looking through the=20 gnucash source, the gnc-spawn-process-async call seems to be spinning up=20 a separate process (well, thread in this case) to handle getting price=20 quotes over the network... -Boris