Pike-devel March 2021

pike-devel@lists.lysator.liu.se

7 participants
16 discussions

Start a nNew thread

Status of pike-www.lysator.liu.se ?
by Stephen R. van den Berg 12 Mar '21

12 Mar '21

Server crashed? -- Stephen.

2 1

Timezone.Runtime_timezone_compiler memory footprint
by Stephen R. van den Berg 11 Mar '21

11 Mar '21

I have been eliminating some memory leaks from the Shuffler, while running my SPike webserver. Things seem to have stabilised now. However, when inspecting the memory footprint, I see the dump at the bottom of this mail. Now, in the grand scheme of things, 850.4kB might not be a lot, but I'm still wondering why it is still being occupied. I mean, I get that because I've been accessing timezones somewhere (though I'm still wondering where exactly), it needs to compile the current timezone. However, after having done that, the timezone compiler should have been freed, and it appears that it is not. Any clues as to why this is happening? ---------------------------------------------------------------------- Object Clones Memory Loc ---------------------------------------------------------------------- imezone.Runtime_timezone_compiler 1 850.4k Timezone.pmod:541 s.Builtin()->multi_string_replace 32 282.1k builtin.cmod:4347 Runtime_timezone_compiler()->Zone 386 151.7k Timezone.pmod:1065 Sql.pgsql_util.conxiin 1 96.5k pgsql_util.pmod:404 Runtime_timezone_compiler()->Rule 139 86.0k Timezone.pmod:811 master()->dirnode 29 81.6k master.pike:2574 MIME.ext_to_media_type 1 65.4k ext_to_media_type.pmod:1659 master 1 47.9k master.pike Standards.ASN1.Types.Identifier 200 42.8k Types.pmod:626 master()->joinnode 30 36.7k master.pike:3013 Parser._parser.HTML 3 24.8k parser.c:196 _static_modules.Builtin()->Search 1 16.1k pike_search.c:188 piler()->__class_66275_0_line_791 1 15.5k Timezone.pmod:792 Standards.PKCS.Identifiers 1 10.0k Identifiers.pmod Calendar.Language.cEN 1 6.3k Language.pmod:525 /main()->SPike 1 5.5k spike:64 Nettle.BufferedCipher()->_Buffer 49 4.2k cipher.cmod:533 sites.pmod 1 4.1k sites.pmod managebackground.pmod 1 3.6k managebackground.pmod Sql.pgsql_util.proxy 1 3.2k pgsql_util.pmod:1965 .Builtin()->single_string_replace 18 2.3k builtin.cmod:4507 Stdio.FILE 4 2.3k module.pmod:1927 Crypto.DH.Parameters 17 2.3k DH.pmod:71 TP.Server.Request()->OutputBuffer 1 2.2k Request.pike:908 Regexp.SimpleRegexp 10 2.2k Regexp.pmod:48 Sql.pgsql_util 1 2.1k pgsql_util.pmod _static_modules._Stdio()->Buffer 4 2.1k buffer.cmod:77 _static_modules.Builtin()->mutex 14 1.9k threads.c:4690 es.Builtin()->DefaultBackendClass 4 1.8k backend.cmod:3253 Pike.Lazy 13 1.8k Lazy.pmod:19 Calendar.ISO 2 1.5k ISO.pmod:11 atic_modules.Builtin()->thread_id 5 1.4k threads.c:4816 /main()->SPike()->regex 12 1.4k spike:459 /main()->SPike()->singleresponse 2 1.2k spike:578 /main()->SPike()->fromfilesystem 7 1.2k spike:610 Thread.Queue 3 1.1k Thread.pmod:241 Stdio.File 2 1.1k module.pmod:188 _static_modules.Gmp()->mpz 4 0.9k mpz_glue.c:2476 Val.Inet 9 0.9k Inet.pike les.Builtin()->Backend()->CallOut 4 0.8k backend.cmod:509 atic_modules.Builtin()->condition 6 0.8k threads.c:4766 _static_modules._Stdio()->Fd 3 0.8k file.cmod:282 Nettle.BlockCipher()->_IGE 7 0.7k cipher.cmod:1606 Nettle.BlockCipher()->_PCBC 7 0.7k cipher.cmod:1450 Nettle.BlockCipher()->_CBC 7 0.7k cipher.cmod:1124 Nettle.BlockCipher()->_OFB 7 0.7k cipher.cmod:3196 Nettle.BlockCipher()->_ABC 7 0.7k cipher.cmod:1987 Nettle.BlockCipher()->_CFB 7 0.7k cipher.cmod:2367 Standards.ASN1.Types.MetaExplicit 6 0.7k Types.pmod:1071 Nettle.BlockCipher()->_CTR 7 0.6k cipher.cmod:2825 odules.Builtin()->pike_trampoline 6 0.5k builtin.cmod:7330 Calendar.Rule.Timezone 5 0.5k Rule.pmod:19 destructed 0 0.0k - ---------------------------------------------------------------------- -- Stephen.

2 1

BA_INIT_ALIGNED
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 08 Mar '21

08 Mar '21

In August 2013, Arne added support for alignment to block_allocator. In doing so, he also introduced a dependency on memalign/posix_memalign. I was planning on rewriting this support to work without memalign, but then I started looking for places which _use_ this functionality, and found none. Pike seems to build just fine without it. If it's dead code, maybe it's better to just remove it?

2 2

Proposal: Built-ins for generators
by Chris Angelico 07 Mar '21

07 Mar '21

A generator function will, when called, return a generator state function. (Are there better terms for these?) It'd be extremely helpful to have a couple of built-in functions to give some info about them. 1) generatorp continue int gen() {continue return 1; return 2;} generatorp(gen) ==> 1 generatorp(gen()) ==> 2 Alternatively, since these are both functions, functionp could return 1 for regular functions, 2 for continue functions, and 3 for continuation functions, but I think a separate generatorp function is better. 2) Function.gen_active function g = gen(); gen_active(g) ==> -1 (Function.NOT_STARTED) g() gen_active(g) ==> 1 (Function.ACTIVE) g() gen_active(g) ==> 0 (Function.ENDED) Once a generator state function is in the ENDED state, calling it will always return UNDEFINED. Having this function available will allow the state to be recognized without an additional call. Open to discussion/bikeshedding on the details, but these functions would be extremely helpful in building an asynchronous system using generators. Opinions? ChrisA

1 0

Re: Possible over-optimization with 'continue return'
by Chris Angelico 05 Mar '21

05 Mar '21

On Sat, Mar 6, 2021 at 7:59 AM Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > > Playing around with generators, and have come across a strange oddity. > > This code works fine: > [...] > > But remove any of the 'if' guards, and the function terminates prematurely. > > > > continue int gen(int x) > > { > > if (x == 1) continue return 1; > > continue return 2; > > if (x == 1) continue return 3; > > return 4; > > } > > > > This will print out 1, 2, 0, and then halt. It appears that perhaps an > > unconditional 'continue return' causes subsequent code to be > > eliminated as if following a hard 'return' statement? > > Indeed. Looks like it is probably a bug in treeopt, where there's > likely some rule that doesn't know about continue return. Thanks for the pointer! Found it, I think. I've pushed it to the branch rosuav/deoptimize-continue-return - would appreciate a second opinion on this! -F_COMMA_EXPR(0 = F_COMMA_EXPR(*, F_RETURN), +[!($$->tree_info & OPT_CASE)]): +// Code after a return statement can be eliminated, as long as +// it's not a 'continue return' statement. +F_COMMA_EXPR(0 = F_COMMA_EXPR(*, F_RETURN(*, F_CONSTANT[!($$->u.sval.u.integer)])), + +[!($$->tree_info & OPT_CASE)]): $0; ChrisA

1 0

Possible over-optimization with 'continue return'
by Chris Angelico 05 Mar '21

05 Mar '21

Playing around with generators, and have come across a strange oddity. This code works fine: continue int gen(int x) { if (x == 1) continue return 1; if (x == 1) continue return 2; if (x == 1) continue return 3; return 4; } int main() { function foo = gen(1); while (1) { int i = foo(); if (undefinedp(i)) break; write("%d\n", i); } } But remove any of the 'if' guards, and the function terminates prematurely. continue int gen(int x) { if (x == 1) continue return 1; continue return 2; if (x == 1) continue return 3; return 4; } This will print out 1, 2, 0, and then halt. It appears that perhaps an unconditional 'continue return' causes subsequent code to be eliminated as if following a hard 'return' statement? ChrisA

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pike-devel March 2021