On Wed, May 10, 2023 at 10:08:09AM +0200, Theo Buehler wrote:
> > Thanks! It has been committed. I doubt though if the Go runtime uses
> > libc malloc.
>
> I don't know if the pure Go runtime uses libc malloc. However, some
> of the test code involves cgo and calls into various C libraries
> incl
> Thanks! It has been committed. I doubt though if the Go runtime uses
> libc malloc.
I don't know if the pure Go runtime uses libc malloc. However, some
of the test code involves cgo and calls into various C libraries
including libcrypto. So it definitely exercised malloc in a threaded
environmen
On Tue, May 09, 2023 at 09:55:32PM +0200, Theo Buehler wrote:
> On Thu, May 04, 2023 at 03:40:35PM +0200, Otto Moerbeek wrote:
> > On Thu, Apr 27, 2023 at 02:17:10PM +0200, Otto Moerbeek wrote:
> >
> > > This was introduced to not stall other threads while mmap is called by
> > > a thread. But no
On Thu, May 04, 2023 at 03:40:35PM +0200, Otto Moerbeek wrote:
> On Thu, Apr 27, 2023 at 02:17:10PM +0200, Otto Moerbeek wrote:
>
> > This was introduced to not stall other threads while mmap is called by
> > a thread. But now that mmap is unlocked, I believe it is no longer
> > useful.
> >
> > A
On Thu, Apr 27, 2023 at 02:17:10PM +0200, Otto Moerbeek wrote:
> This was introduced to not stall other threads while mmap is called by
> a thread. But now that mmap is unlocked, I believe it is no longer
> useful.
>
> A full build is slighlty faster with this. But this also needs testing
> with
This was introduced to not stall other threads while mmap is called by
a thread. But now that mmap is unlocked, I believe it is no longer
useful.
A full build is slighlty faster with this. But this also needs testing
with you favorite multithreaded program.
-Otto
Index: stdlib/malloc.c
=
