Pike-devel May 2026

pike-devel@lists.lysator.liu.se

4 participants
7 discussions

Process.run() after fork() fails on Pike 9.0
by H. William Welliver 19 May '26

19 May '26

Hi all, While working on getting some code ready for Pike 9, I ran into what seems to be a regression: when forking a process into the background, Process.run() called in the child process seems to hang. I was able to confirm this behavior on macOS and illumos, so I don’t think it’s platform specific. I’ve attached a fairly minimal test case that demonstrates the problem: data should be written to the log file each second but the initial call to Process.run() never returns and so only the very first log message is generated. I’ve confirmed that Pike 8 does not have this behavior. I’m hoping that someone more familiar with the Process module will have an idea of what’s going on. Thanks in advance! https://paste.sr.ht/~hww3/504e8244449110b5646f0267a5c0cb7e1b154206

2 3

Pike Meet-up 2024-Q2
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 18 May '26

18 May '26

Hi. At Pike Conference 2017 it was decided that we ought to hold a more informal meeting in Linköping ~ once every quarter. As the 6 month mark from the latest conference is coming up soon, it seems time to announce the second such meeting for 2024: Pike Meet-up 2024-Q2 Date: 2024-05-11 (Sat) Time: 10:00 - afternoon/evening Place: Roxen IS AB Storgatan 46 Linköping Welcome! /grubba

2 8

Pike 9.0.11 (beta 3) released.
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 10 May '26

10 May '26

The above is now available for download from the Pike site. Please test and enjoy. /grubba

1 1

Re: Slow promise awaiting when large amounts of data transmitted
by Chris Angelico 07 May '26

07 May '26

On Wed, 6 May 2026 at 18:07, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > > > I wonder if it would be reasonable to have a cut-down backtrace > > > display that doesn't show the contents of mappings or arrays, so the > > > function arguments would be shown as some_function(([...])) instead of > > > the full details. That still would keep the most relevant parts of the > > > traceback, and could retain strings and numbers, but would prevent > > > unbounded growth. > > > > Yes, that would solve the main issue. > > Try now. > Hmm. It's definitely made the change, and yet something's still slow. Welp. I guess it's time for me to make a cut-down demonstration case so we can figure this out. Will report back once I've made a version of my Twitch bot where it doesn't need a database or anything but still has the problem. ChrisA

1 3

Re: Slow promise awaiting when large amounts of data transmitted
by Chris Angelico 06 May '26

06 May '26

On Mon, 4 May 2026 at 18:16, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > Could the Promise retain the backtrace as an array of frames, rather > > than describing it immediately and retaining the string? That is also > > fast (since most of the time it doesn't need to display anything), but > > will still produce equivalent output. Or would that result in a > > reference loop? > > The reason for the backtrace being saved as a string is indeed to > avoid reference issues. One possibility could be to truncate the > backtrace to just a few frames. > I wonder if it would be reasonable to have a cut-down backtrace display that doesn't show the contents of mappings or arrays, so the function arguments would be shown as some_function(([...])) instead of the full details. That still would keep the most relevant parts of the traceback, and could retain strings and numbers, but would prevent unbounded growth. ChrisA

2 2

Re: Slow promise awaiting when large amounts of data transmitted
by Chris Angelico 04 May '26

04 May '26

On Mon, 4 May 2026 at 16:30, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > > Having a large blob of data returned from an await() results in all > > subsequent awaits to slow down. Example: > > > > __async__ void reconnect() { > > mapping commands = await(load_commands()); //Returns a big array > > //werror("This should be a one: %O\n", > > await(Concurrent.resolve(1))); //Returns just an integer > > foreach (commands; string uuid; mapping data) do_stuff_with(uuid, data); > > } > > Wow! Somebody (other than me) is already using __async__ and await()! I sure am! I love it and use it in all my projects now, pretty much. My main Twitch bot (Mustard Mine) switched over to that back when they were "continue functions" and without a moment's hesitation I moved to proper async/await. > Concurrent.Promise et al should be agnostic with respect to the size > of data that is passed. As you have noted though, due to it saving > the backtrace at time of creation, the size of the backtrace will > affect timing. > > > If do_stuff_with() involves multiple promises/awaits, each one has a > > notional backtrace involving the entire large array. The inclusion of > > the dummy resolve(1) changes this so that the earlier call in the > > backtrace is much smaller. > > Try disabling the orig_backtrace handling (eg initialize it to "" > instead of the backtrace) in Concurrent.pmod, and see if it solves > your issue. Yes, hacking that out does prevent the problem. > > I'm not sure what changed recently, but when I upgraded Pike, this > > started to be slow. However, Concurrent.pmod doesn't seem to have > > changed recently, so I'm not sure what the cause is. (It's also > > possible an unrelated change of my own triggered this.) > > One easy way to reduce the backtrace size is to wrap the large value > in an object when passing it as an argument. I could do that. I'd have to figure out how much of a nuisance that'd be API-wise, since I don't know how much of a problem it's going to be. Notably, this is only really a problem when there are a *lot* of promise backtraces being generated (the code I posted above is simplified, but there's several layers of iteration and calls - this is loading roughly a hundred channel's worth of data, then for each channel, going and setting things up). > > Promises currently seem to retain a text backtrace. I'm not sure if > > that's relevant or not, as it has always been there, but it may be > > connected. > > They have been there for quite a while, albeit they were not enabled > by default initially. They were enabled by default as they were so > useful when debugging problematic Promises. > Ah, interesting. I thought that change happened years ago though, so I didn't think that was the cause. Could the Promise retain the backtrace as an array of frames, rather than describing it immediately and retaining the string? That is also fast (since most of the time it doesn't need to display anything), but will still produce equivalent output. Or would that result in a reference loop? ChrisA

3 3

Slow promise awaiting when large amounts of data transmitted
by Chris Angelico 04 May '26

04 May '26

Having a large blob of data returned from an await() results in all subsequent awaits to slow down. Example: __async__ void reconnect() { mapping commands = await(load_commands()); //Returns a big array //werror("This should be a one: %O\n", await(Concurrent.resolve(1))); //Returns just an integer foreach (commands; string uuid; mapping data) do_stuff_with(uuid, data); } If do_stuff_with() involves multiple promises/awaits, each one has a notional backtrace involving the entire large array. The inclusion of the dummy resolve(1) changes this so that the earlier call in the backtrace is much smaller. I'm not sure what changed recently, but when I upgraded Pike, this started to be slow. However, Concurrent.pmod doesn't seem to have changed recently, so I'm not sure what the cause is. (It's also possible an unrelated change of my own triggered this.) Promises currently seem to retain a text backtrace. I'm not sure if that's relevant or not, as it has always been there, but it may be connected. Any ideas what's going on here? ChrisA

2 1

2026

2025

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 May 2026