diary at Telent Netowrks

To pacify the end-of-month bug, here is another placeholder#

Thu, 01 Jul 2004 13:41:52 +0000

To pacify the end-of-month bug, here is another placeholder. Without going into any particularly interesting details, this one says that

A review of my new cheap hardware MP3 player will follow (summary for#

Sun, 04 Jul 2004 22:50:00 +0000

A review of my new cheap hardware MP3 player will follow (summary for the impatient: it was cheap). Right now I'm merely noting that it provided an impetus to clear some disk space on my laptop.

:; pwd
/home/dan/.emacs.d/auto-save-list
:; du .
4238340 .

Does that seem like a lot?

Announcing BORDEAUX-MP, a proposed standard interface for MP in Lisp#

Fri, 09 Jul 2004 16:53:01 +0000

Announcing BORDEAUX-MP, a proposed standard interface for MP in Lisp. (No, I haven't ever tried this before). Discussion on the new threads-standard-discuss list.

Which list is one of a matching set of three; the other two being for discussion of the MOP and for extensible (eg Grey, simple-) streams. There's not been a lot of blogging done from LSM that I can see (at least, not in our own private little Lisp world) and I'm not going to start now (I will later), but Christophe Rhodes is compiling "proceedings" of yesterday's lightning talks, so please look out for those.

Random bits of post-LSM notes, many inconsequential#

Sat, 10 Jul 2004 23:39:30 +0000

Random bits of post-LSM notes, many inconsequential.

I have some thoughts about Protocol-Oriented Programming (one of the topics touched on in the formal presentation on Tuesday) and Smalltalk (the other people in our track on Tuesday), which will wait for another diary entry. There's also much more to say about the protostandards stuff, which is waiting on the others involved to reply to their email, and about lightning presentations, but Christophe Rhodes is collating that not me.

Oh, yeah. And I have an (entirely untested) first cut at a BORDEAUX-MP implementation for SBCL, which will shortly be committed to CVS

I'm finding more SBCL threading bugs: so far, the count is three bugs#

Fri, 16 Jul 2004 01:12:31 +0000

I'm finding more SBCL threading bugs: so far, the count is three bugs and two fixes.

Edi Weitz pointed out recently that his cl-ppcre libarry comes with a test suite whose threading tests fail when run under SBCL, so I've been working on that. So far

  1. Bad header file ordering in the runtime was causing the non-threaded versions of spinlock get/release inline functions to be compiled in some places even on a threaded build. (Fixed)

  2. SIGCHLD will call destroythread, which is fair enough, but not if you're holding allthreads_lock already because it wants to acquire it. (Fixed)

  3. After beating on the threading for long enough it's still somehow possible to get into a state where GC wants to stop a thread so that it can collect the heap, but the thread has disappeared. Not fixed

Thread bug 3 identified#

Mon, 19 Jul 2004 01:39:59 +0000

Thread bug 3 identified. Background: gcstoptheworld is called from within a WITHOUT-INTERRUPTS form. WITHOUT-INTERRUPTS doesn't actually mask signals at the kernel level, but does set a flag that the C-level signal handlers check when deciding whether to defer a signal. SIGTHREAD_EXIT (the RT signal that the parent thread is sent when a child thread dies, a la SIGCHLD for traditional processes) is on the deferrable list (because it calls Lisp code), so if a thread dies between the start of WITHOUT-INTERRUPTS and the world getting stopped, there's nothing available to wait() for it. Thus it becomes a zombie and will never react to requests to suspend itself for GC.

Alternate strategy: make threadexithandler just wait() and then set thread->state=STATEDEAD, so the GC can see the thread's no more, then do the Lisp-level stuff and destroythread at some later time. Now we can remove SIGTHREADEXIT from the deferrable list. Pretty arbitrarily, we've decided that at "after a GC" would be a reasonable later time; so now if you disable GC you have also disabled dead thread collection.

I've had this laptop (Toshiba Portégé 3440CT) for#

Tue, 20 Jul 2004 00:17:07 +0000

I've had this laptop (Toshiba Portégé 3440CT) for something over three years now, and I'm still pretty happy with it, mostly. Yes, it's old and underpowered (500MHz mobile PIII), but it weighs practically nothing, it has a trackpoint thing, three mouse buttons (actually, two buttons and two scrollwheel simulating buttons but I can remap one of those as button 3 and it mostly works apart from slightly evil autorepeating behaviour), and it's old enough to use APM not ACPI. Which during most of its early life was a distinct advantage on a machine that runs Linux.

It does have a few oddities, though; readers may recall its habit of saving power by randomly frobbing CPU speed and not telling the OS. This is not in itself a problem now I've weaned Linux away from using the TSC as a time source, and probably also saving some power, but the manner of its doing was starting to annoy me, in that it will decide apparently at random that it should only speed up as far as 266MHz. Usually it can be persuaded to speed up again by removing and reapplying mains power, but after a while (and lately it seems to be quite a short while) it's forgotten again. This is tedious when recompiling SBCL.

Today I found that (a) the version of toshset that I already have installed has an option for cpu speed, (b) it was set to 'low', (c) setting it to 'high' does actually make a difference, and to cap it all (d) the cpu speed still varies continuously according to system load, so as I mostly use well-behaved apps that only eat cpu when they're actually doing things (exception made for the ISC dhcp client which from time to time likes to spin on CPU), I still get the battery savings. Happy Bunnies R Us.

Re: [Sbcl-devel] Status of native thread support#

Tue, 20 Jul 2004 01:07:04 +0000

Bcc: dan
To: sbcl-devel <at> lists.sourceforge.net
Subject: Re: [Sbcl-devel] Status of native thread support?
Edi Weitz writes:
> FWIW, I just tried the threaded CL-PPCRE tests again (I had an email
> exchange with Cristophe about this some months ago) and they still
> fail with SBCL 0.8.12 on Debian unstable. (Kernel is 2.6.6.) They run
> fine with Lispworks' green threads and they used to run fine with
> Scieneer's native threads when I had access to their 1.1 trial
> version.
The CL-PPCRE thread tests seem to work quite nicely as a test of
thread creation/exiting, which had a number of exciting race
conditions.  You may (and everyone else using or wanting to use
threaded SBCL may also) want to check out 0.8.12.42 which fixes at
least three of these and seems to run the threaded tests in cl-ppcre
0.7.9 quite happily.
This also fixes the thundering herd at thread gc rather more cleanly
than inserting sched_yields around the place: thanks to Juho Snellman
and Christophe Rhodes on #lisp for pointing this stuff out.
So, unless Bill advises to the contrary, SBCL will shortly be going
into code-mostly-freeze for the 0.8.13 release.  Therefore it would be
a really good thing if people would test their threaded stuff for
regressions /now/ instead of leaving it a week: then any bugs can be
fixed in time for this month instead of next.
(Incidentally, your threaded-scan function seems to be doing incf of
a shared variable COUNTER without the aid of a lock; this is probably
not guaranteed to work everywhere.  I think it happens to work in SBCL
(if so, mostly because it happens to work on x86), but you probably
want to have some kind of atomic-incf there, or protect it with a
mutex)

-dan
-- 
"please make sure that the person is your friend before you confirm"

I'm playing with last.fm#

Thu, 29 Jul 2004 20:00:23 +0000

I'm playing with last.fm. A few months ago I got annoyed at some of the wailing and teeth-gnashing that was happening on uk.music.guitar and posted an article saying approximately "if the `channel' sucks so much anyway, stop complaining that you can't break into it and start routing around it". Then I completely omitted to do any of the things I'd suggested that people start doing. But it seems like last.fm is doing at least some of them - at least the technical bits - even if so far it's mostly just playing stuff at me that I've already heard of. First impressions: really rather cool, but minor downsides: does come unsynced every so often (the stream is not playing what the popup window says it's playing) and involves way more screen space than I think it needs to use.

I registered as 'telent', but I don't think it knows enough about me yet for it to be worth anyone's time going to find me there right now.

Earlier this week I hacked up some inline allocation routines for#

Fri, 30 Jul 2004 10:14:49 +0000

Earlier this week I hacked up some inline allocation routines for SBCL. Each thread already has its own region, so Lisp code should be able to allocate within that region just by incrementing the (thread-local) free pointer, rather than calling into C for every 8 bytes. And now it can.

(For a long time pre-threading it used to be able to do this, but it was using a global variable to store the free pointer which was obviously not going to fly in an MP environment, so I ripped out that code when initially doing threads)

After a minor misapprehension regarding whether it would make any useful difference (summary: 5% to 15% speedup on some consy benchmarks), I've merged this change (or reinstation, if you prefer) into 0.8.13.11

⟪Jun 2004 Aug 2004⟫