From: adr <adr@SDF.ORG>
To: 9fans <9fans@9fans.net>
Subject: Re: [9fans] Re: _threadmalloc() size>100000000; shouldn't be totalmalloc?
Date: Tue, 28 Jun 2022 14:21:13 +0000 (UTC) [thread overview]
Message-ID: <f9acc60-147c-8ce9-1b20-caad249e8e87@SDF.ORG> (raw)
In-Reply-To: <CAEoi9W5wUD4uoBD8_hhq-BSNGd-XovJ62ytuD3NrbsvYzOHH3g@mail.gmail.com>
On Tue, 28 Jun 2022, Dan Cross wrote:
>>> [...]
>>> void*
>>> _threadmalloc(long size, int z)
>>> {
>>> void *m;
>>>
>>> m = malloc(size);
>>> if (m == nil)
>>> sysfatal("Malloc of size %ld failed: %r", size);
>>> setmalloctag(m, getcallerpc(&size));
>>> totalmalloc += size;
>>> if (size > 100000000) {
>>> fprint(2, "Malloc of size %ld, total %ld\n", size,
>>> totalmalloc);
>>> abort();
>>> }
>>> if (z)
>>> memset(m, 0, size);
>>> return m;
>>> }
>>> [...]
>>>
>>> Shouldn't the if statement test the size of totalmalloc before the
>>> abort? That size, 100M for internal allocations? It has to be
>>> totalmalloc, doesn't it? If not this if statement should be after
>>> testing the success of the malloc. Am I missing something?
>
> Note that the `if` statement doesn't test the size of *totalmalloc*, but
> just `size`. `totalsize` is only incidentally printed in the output if `size`
> exceeds 100 MB: that is, if a single allocation is larger than 100MB.
I know, what called my attention is that size wasn't tested before
calling malloc, so the first thought I had was that the code had
a typo and it should be testing totalmalloc instead.
>> I mean, I think using libthread more like using small channels and thread's stack sizes, but:
>>
>> Why put a limit here to size when totalmalloc could continue to grow until malloc fails?
>>
>> If we want a limit, why don't we take into account the system resources?
>>
>> If we want a constant limit, why don't we put it on threadimpl.h, explain why this value in a comment
>> and document it in thread(2)?
>>
>> Why bother to call malloc before testing if size exeeds that limit???
>
> Given the name of the function (`_threadmalloc`), I'd guess that this isn't
> intended for general use, but rather, for the internal consumption of the
> thread library, where indeed such a large allocation would likely be an
> error (bear in mind this code was developed on 32-bit machines with RAMs
> measured in Megabytes, not Gigabytes).
No, it's used also when creating a channel and setting a thread's
stack size.
adr
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te1be8dc72738258d-Mcbc484781129f693c26365ef
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
next prev parent reply other threads:[~2022-06-28 14:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-26 9:50 [9fans] " adr
2022-06-28 13:00 ` [9fans] " adr
2022-06-28 13:50 ` Dan Cross
2022-06-28 14:21 ` adr [this message]
2022-06-28 14:32 ` Dan Cross
2022-06-28 15:36 ` adr
2022-06-28 15:57 ` Dan Cross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f9acc60-147c-8ce9-1b20-caad249e8e87@SDF.ORG \
--to=adr@sdf.org \
--cc=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).