Hi,
I'm currently looking for jobs in french research centers as a research engineer. I found
an open position in LIP (Lab of parallel programing, CNRS, Lyon, France) that is part of a
joint research unit with the Bell Labs, but I can't find any reference to Plan 9 in their
work.
Do you, Pl
Tristan Plumb <9p...@imu.li> writes:
>> Anyone working on or have a simple SIP router/proxy for Plan9? As of
>> today I will no longer waste days of my life dealing with the
>> abomination that is Asterisk.
> I would also love to see a SIP implementation for Plan 9, I've
Here here! I'd also lov
i couldn't work out which hardware, usable by Asterix, could be
driven by another system instead.
Hi,
in pc/main.c idlehands() the kernel decides to release the CPU only
when you are not running a multicore kernel. As a result there is only
busy waiting. Unfortunately there is no hint telling why we do not let
the CPU rest a little.
> void
> idlehands(void)
> {
> if(conf.nmach == 1)
>
On Fri Jul 1 13:06:36 EDT 2011, henn...@plan9.bell-labs.com wrote:
> in pc/main.c idlehands() the kernel decides to release the CPU only
> when you are not running a multicore kernel. As a result there is only
> busy waiting. Unfortunately there is no hint telling why we do not let
> the CPU rest
The hlt instruction on x86 leaves the halt state after an external
interrupt is fired. I'm not sure why you think it doesn't work? If you
need to wake up other cores then you may need IPIs is that what you
mean?
~ Ali
On Fri, Jul 1, 2011 at 10:23 AM, erik quanstrom wrote:
> On Fri Jul 1 13:06:3
On Fri, Jul 1, 2011 at 1:47 PM, Ali Mashtizadeh wrote:
> The hlt instruction on x86 leaves the halt state after an external
> interrupt is fired. I'm not sure why you think it doesn't work?
he didn't say it didn't work.
he said it required waiting for the next interrupt,
of which the only guarant
>
> interprocessor interrupts are the obvious solution
> but no one has bothered to implement them.
>
i almost mentioned this, and it's on my list. i just haven't
had the time. it turns out that a naive implementation of
ipi'ing 1 proc per wakeup will have to watch out for the
same races that
On Fri, 01 Jul 2011 14:01:28 EDT erik quanstrom wrote:
> >
> > interprocessor interrupts are the obvious solution
> > but no one has bothered to implement them.
> >
>
> i almost mentioned this, and it's on my list. i just haven't
> had the time. it turns out that a naive implementation of
>
there's a fix to a long-standing (but silly) bug in the 9atom's
screen.c that gives 10x the video performance. if you're using
a terminal with 9atom you may be interested in upgrading to
a new kernel.
enjoy.
- erik
this got lost in a large patch that didn't get accepted, and i just turned it
up. i'd hate for
anyone else to trip over the same troubles. this fixes
- sneaky UTFmax dependencies
- a bug if %r is given with no matching format for rune r, where r>127.
- %, interacting badly with 0 padding.
- bad
On i386 systems with MONITOR/MWAIT, you could use them; simpler than
adding support for IPIs, I imagine.
-- vs
12 matches
Mail list logo
