Skip to content

Conversation

@vgmoose
Copy link

@vgmoose vgmoose commented Jul 30, 2021

This is for the issue in #146 with the process count limit being hit. This PR defaults to 32 and lets the user supply their own value.

I'm unsure of the implications of making old_results no longer static, but changing it allows the user-supplied variable to be used instead.

Usage:

./progress -t 64

Another solution might be to scan for the processes first to get an upper count, before going on to fill the array with the process info, to not need a count supplied with >32 processes.

@Xfennec Xfennec mentioned this pull request Sep 16, 2021
@Xfennec
Copy link
Owner

Xfennec commented Oct 13, 2023

I added this PR on my todo list… and never got time to unstack it. Sorry for that!

The issue with the current patch is that removing the static nature of old_results may compromise the watch feature (we need persistent memory between each copy_and_clean_results() call).

It currently sort of works because the compiler does not reallocate between call, but it's an happy accident 😅 .

Making old_results global and allocate on startup would be a quick and dirty fix for this, I guess.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants