dorin bumbu | 3 Nov 16:40 2010
Picon

multicast?

is there a fault-tolerant multicast framework for inferno (or plan 9)
that delivers messages in causal and total order to a group of
servers?

Dorin

rod | 8 Nov 14:33 2010
Picon

usbd in limbo

I am trying to find limbo versions of usbd and the usb disk driver
which work with the new (#u) plan9 usb drivers. There is tantalising
mention that they exist on the web but I've had no luck locating them. 

Rod

Venkatesh Srinivas | 16 Nov 05:15 2010

Inferno status?

Hi,

It's been more than a month since the last commit to inferno-os; does
anyone know what sort of things are going on with it these days?

In inferno-npe, here's what gone on in the last month or so:
* Merge with latest inferno-os
* Import NMEAlib into the C part of the code. NMEAlib is a library to
parse the standard NMEA serial GPS protocol; it has not yet been
wrapped for access from Limbo, but that will likely happen soon.

* On DragonFly BSD, Inferno was not reliably starting; the problem was
traced to a race between an osblock() and osready().

osblock() and osready() are routines in the Inferno runtime that cause
a host thread to block or to resume, respectively. They are used in
Inferno's QLocks, Rendezvous, sleep, etc. osblock() and osready() are
edge-triggered - that is, if an osready() and osblock() are not
synchronized in a higher-level way, there is the possibility of a
missed wakeup. The UNIX ports all use a sigsuspend() / signal pair to
implement osblock() / osready().

I converted the DragonFly version of osblock/osready to be
level-triggered as opposed to edge-triggered and to use the platform's
umtx_* syscalls for blocking/waking. This also sped up Inferno on DFly
a bunch. The new versions are in emu/DragonFly/os-386.c, as they use
the i386 XADD instruction.

(simplified)
void osblock() {
(Continue reading)

Alex Efros | 16 Nov 05:56 2010

Re: Inferno status?

Hi!

On Mon, Nov 15, 2010 at 11:15:43PM -0500, Venkatesh Srinivas wrote:
> * On DragonFly BSD, Inferno was not reliably starting; the problem was
> traced to a race between an osblock() and osready().
[...]
> When I tried to do the same on Linux, replacing the signal pair with
> futexes, Inferno got a bit slower on the thread-ring, chameneos, and a
> tar-ing test (tar up /n/sources/sys/src/9).

I've experienced hangs when starting Inferno on Linux, but was unable to
reproduce this issue: after killing that emu with Ctrl-C and starting it
again everything works fine. Also this happens very rare - about once per
few months or so.

So, if you think you fixed this issue, I'll be happy to see this fix in
mainline inferno-os. Or at least separate patch for this fix attached in
inferno-os issue tracker.

--

-- 
			WBR, Alex.

Charles Forsyth | 16 Nov 10:46 2010
Picon

Re: Inferno status?

>osblock() and osready() are edge-triggered - that is, if an osready() and osblock() are not
>synchronized in a higher-level way, there is the possibility of a
>missed wakeup.

does linux not implement reliable signals (cf. POSIX) or is the code
not using them correctly? they should not act as `edge-triggered' as you put it.

Charles Forsyth | 16 Nov 14:37 2010
Picon

Re: Inferno status?

>osblock() and osready() are edge-triggered - that is, if an osready() and osblock() are not
>synchronized in a higher-level way, there is the possibility of a
>missed wakeup.

the names osblock and osready suggest the function, but not another of
their properties: there is no race. the implementation must
provide sufficient synchronisation to ensure that (ie, synchronized
in a lower-level way!), when it matters. either a semaphore (explicitly or implicitly)
or plan 9's rendezvous are sufficient implementations.
Irix provides an implicit semaphore through blockproc/unblockproc.
(the implementation using signals was either inherited or adapted
from a more eleaborate version that implemented rendezvous, but
that missed part of the point.)

Venkatesh Srinivas | 19 Nov 15:02 2010

Limbo question

Hi,

From appl/lib/vac.b:

insertsort[T](a: array of T)
        for { T =>      cmp:    fn(a, b: T): int; }
{
   ...
}

What is the for { }... doing there?

-- vs

C H Forsyth | 19 Nov 15:53 2010

Re: Limbo question

>What is the for { }... doing there?

it says that any parameter type T must have an operation `cmp'
with the given signature. it allows `insertsort' to compare values
of any given type T (that has such an operation).

it's the analogue of CLU's `where' clause.

Venkatesh Srinivas | 20 Nov 04:16 2010

Re: Limbo question

On Fri, Nov 19, 2010 at 9:53 AM, C H Forsyth <forsyth@...> wrote:
>>What is the for { }... doing there?
>
> it says that any parameter type T must have an operation `cmp'
> with the given signature. it allows `insertsort' to compare values
> of any given type T (that has such an operation).
>
> it's the analogue of CLU's `where' clause.
>

Aha, okay, thanks.

Trying it out, it seems to only work for adts that have a function to
match, not for data types. Is that the case? (if so, any reason?).

Is this documented anywhere?

Thanks,
-- vs

Charles Forsyth | 20 Nov 12:27 2010
Picon

Re: Limbo question

>Trying it out, it seems to only work for adts that have a function to
>match, not for data types. Is that the case? (if so, any reason?).

actual type parameters can only be reference types, with the usual special exception for string
and as you say, currently the extra constraints of the for clause
only allow types that refer to adts with the given function name.

as well as the annoying restriction to reference types, imposed for
the same reason as a similar addition to Oberon (`Lightweight Polymorphic Types'),
the constraints in the for clause sometimes need to be repeated, which
feels like once too often.

that's why we haven't made a big noise about it, but just tried it out
here and there. you'll see it mentioned in several entries on the bug
list in google code.

the intention is to sort it all out.


Gmane