3 Nov 2010 16:40
8 Nov 2010 14:33
16 Nov 2010 05:15
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)
16 Nov 2010 05:56
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.
16 Nov 2010 10:46
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.
16 Nov 2010 14:37
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.)
19 Nov 2010 15:02
19 Nov 2010 15:53
20 Nov 2010 04:16
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
20 Nov 2010 12:27
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.
RSS Feed