9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
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

  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).