Updated proposal:
In the existing implementation, even though the manpage doesn't say so,
PT_STEP will take the value in the data argument (4th argument) as the
signal to deliver, exactly as for PT_CONTINUE. (For that matter, it
also looks at the 3rd argument, addr, in the same way as PT_CONTINUE
On Wed, Mar 17, 2010 at 03:40:13PM +, Sad Clouds wrote:
> On Wed, 17 Mar 2010 16:07:04 +0100
> Manuel Bouyer wrote:
>
> > On Wed, Mar 17, 2010 at 12:50:51PM +, Sad Clouds wrote:
> > > [...]
> > > I profiled a simple event driven server, with 5000 simultaneous
> > > connections. About 80%
It appears that this patch works. I believe the submitter was working
on Ruby 1.9 on NetBSD, and ran into this (which I also did.)
The supplied patch works on my netbsd-5 branch test box, and should also
apply for current.
I'd like to commit it (and request a pull-up to netbsd-5). Any reason I
On Tue, Mar 23, 2010 at 07:03:11PM -0700, Michael Graff wrote:
> I'd like to commit it (and request a pull-up to netbsd-5). Any reason I
> shouldn't?
What is the real problem here? fork(2) of a multithreaded program is
essentially "Here be dragon's" terrain. So I don't think why it matters
at all
On 3/23/10 7:08 PM, Joerg Sonnenberger wrote:
> On Tue, Mar 23, 2010 at 07:03:11PM -0700, Michael Graff wrote:
>> I'd like to commit it (and request a pull-up to netbsd-5). Any reason I
>> shouldn't?
>
> What is the real problem here? fork(2) of a multithreaded program is
> essentially "Here be d
yeah.
while i agree with joerg that these operations aren't well defined, we
can do something a bit more sane like this patch.
i think it's OK.
.mrg.
I'd like to propose a new function in bus_space(9) API, bus_space_physload(9).
void *bus_space_physload(bus_space_tag_t space, bus_addr_t addr,
bus_size_t size);
This function is provided for device drivers to register its linear memory
region to be managed by VM. When user p
