On Fri, 11 Jun 2021 06:10:22 GMT, Thomas Stuefe wrote:
> Would it not be better to read the whole content of /proc/stat with a single
> read() call instead of line by line? I don't think proc fs guarantees any
> kind of consistency with separate reads.
yes, so fgetc's return value should need
On Mon, 14 Jun 2021 14:00:14 GMT, UncleNine
wrote:
> @UncleNine please do not force push commits to an open PR as it makes it
> difficult for reviewers to track the changes. The PR can contain as many
> commits as you like as it will all be squashed to a single clean co
On Tue, 8 Jun 2021 16:28:34 GMT, UncleNine
wrote:
>>> If the /proc/stat mount point is changed in container environment, the
>>> while loop may lead to 100% cpu usage.
>>
>> In what way have you observed /proc/stat being changed which manifests in
>> 100%
On Sun, 6 Jun 2021 14:47:31 GMT, UncleNine
wrote:
> If the /proc/stat mount point is changed in container environment, the while
> loop may lead to 100% cpu usage.
This pull request has now been integrated.
Changeset: 72672277
Author:UncleNine
Committer: Severin Gehwol
> If the /proc/stat mount point is changed in container environment, the while
> loop may lead to 100% cpu usage.
UncleNine has refreshed the contents of this pull request, and previous commits
have been removed. The incremental views will show differences compared to the
previous cont
> If the /proc/stat mount point is changed in container environment, the while
> loop may lead to 100% cpu usage.
UncleNine has refreshed the contents of this pull request, and previous commits
have been removed. The incremental views will show differences compared to the
previous cont
ontent.com/1964054/121224813-81612900-c8bb-11eb-80e1-29d15989dc17.png)
>
> @UncleNine We should handle the case in the `get_totalticks()` function -
> which seems to be the only user of `next_line()` - when `next_line()` returns
> EOF as David said. One way would be to return the '
> If the /proc/stat mount point is changed in container environment, the while
> loop may lead to 100% cpu usage.
UncleNine has updated the pull request incrementally with one additional commit
since the last revision:
8268361: Fix the infinite loop in next_line
-
C
On Tue, 8 Jun 2021 16:21:34 GMT, UncleNine
wrote:
>> It is not obvious to me that the caller of next_line will handle the fact
>> that we have hit EOF?
>
> In my case, it happened in the container environment.
> the /proc filesystem of the container is provided by l
On Tue, 8 Jun 2021 08:39:21 GMT, Severin Gehwolf wrote:
> > If the /proc/stat mount point is changed in container environment, the
> > while loop may lead to 100% cpu usage.
>
> In what way have you observed /proc/stat being changed which manifests in
> 100% cpu usage?
In my case, it happened
On Tue, 8 Jun 2021 06:39:12 GMT, David Holmes wrote:
>> src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c line
>> 70:
>>
>>> 68: do {
>>> 69: c = fgetc(f);
>>> 70: } while(c != '\n' && c != EOF);
>>
>> Style nit: please add space before (
>
> It is not obv
> If the /proc/stat mount point is changed in container environment, the while
> loop may lead to 100% cpu usage.
UncleNine has updated the pull request incrementally with one additional commit
since the last revision:
8268361: Fix the infinite loop in next_line
-
C
If the /proc/stat mount point is changed in container environment, the while
loop may lead to 100% cpu usage.
-
Commit messages:
- Fix the dead loop.\nSummary: If the /proc/stat mount point is changed in
container environment, the while loop may lead to 100% cpu usage.
Changes: ht
13 matches
Mail list logo
