Re: Wild PID's

vandys@cisco.com writes:

>Pretty much... the floppy server spins up a thread when he needs timing
>support. That'd cause you to work your way through PID's. It's
>probably
>also a symptom that something needs to be optimized. :->

Oh, yeah... I saw that before, but I didn't make the connection :)

PID's only have to be unique, so it was just a curiousity rather than an
actual problem. If a message loop wants to be notified of a timer event,
it would have to create a thread, true; but I was under the impression
that tfork'ing (and even forking) under VSTa was pretty efficient?
(maybe not 3000 times in a row, though. :)

Speaking about the floppy driver, I had to make a couple of changes
to make it work on a boot disk. After getting it to link as a boot
server,
the floppy driver would crash trying to allocate the bounce buffer on
certain systems. The error was EBUSY, which I assume was generated
by mach_page_wire(), noticing that the original page had already been
attached to some physical memory. I'm probably not explaining this
right, and I didn't really understand what I was doing, but on a whim
I changed the malloc() in fd to a direct mmap() for anonymous memory,
and lo and behold, it started working. I'm still not sure what happened
though. Does malloc always commit to physical memory? It doesn't
seem like it should.
Received on Tue May 25 18:09:09 1999