pthreads progress: threads.impure.lisp no more broken than usual#
Fri, 04 Mar 2005 14:25:04 +0000
pthreads progress: threads.impure.lisp no more broken than usual. After implementing (and then fixing (with thanks to Juho, again)) interrupt-thread, the test
file appears to pretty much work. Except for the bit where it
assumes thread ids are pids and therefore acceptable to
sb-unix:unix-kill, anyway.
Next step: port this forward (which should be trivial), fix it to
not break clone()threads (#ifdef), merge it on HEAD. Next next step:
even those users who didn't find it icky that we exposed pids to Lisp
as thread ids will be upset by our similar use of the pthreads
thread_t. So, some kind of object representation of the thread would
be nice.
There is one thing more that needs doing for SBCL/pthreads: futex#
Sun, 06 Mar 2005 00:13:13 +0000
There is one thing more that needs doing for SBCL/pthreads: futex
removal. It looks like we can almost replace them with POSIX 1003.1b
semaphores, but for one small problem
<dan-b> I feel a sudden need to say ARGH ARGH ARGH
<dan-b> I wonder what happens if GC moves a waitqueue struct while threads
are waiting on it
<pfdietz> 'Bad Things'?
<dan-b> I can think of no reason for that not to be the case, certainly
<dan-b> maybe it just never happens because there's a reference to
the struct on the stack of one or more of the participating threads
<dan-b> from the arglist to get-mutex or whatever
<dan-b> actually I could believe that
<dan-b> | Only sem itself may be used for performing synchronisation. The
result of referring to copies of sem in calls to semwait(),
semtrywait(), sempost(), and semdestroy(), is undefined
<dan-b> looks like pthreads is going to have bigger problems, though
<dan-b> even unlocked semaphores are now immovable
(quote is from the sem_init specification)
waitqueue was a perfectly ordinary struct. I think I'm going to have
to make it a primitive object so that I can teach GC how to move it
safely (semdestroy, move, seminit in new location). Sigh. Or keep
the semaphores in not-lisp-memory, and account for them by hand. Or
initialise them when first needed (when something wants to wait) and
destroy them again as soon as all threads are no longer waiting. Or
go to bed and see if any better ideas occur to me tomorrow.
Cliki (and this blog) was down for a couple of hours this morning#
Wed, 09 Mar 2005 15:47:34 +0000
Cliki (and this blog) was down for a couple of hours this morning.
It's up again now, and apparently has new CPU, motherboard and PSU.
All those years ago when writing the CLiki Privacy
Statement, I failed to foresee a need to publish excerpts from
server logs for the purpose of ranting about spammers. So instead of
spewing a bunch of grep output from one recent cliki spam, I'd better
just tell you that
- He seems to be a human using an ordinary web browser, not a
script. This also holds for the other recent front page defacement
that I checked. And his IP address (which comes from "CNCGROUP
Beijing province network") isn't on any more DNS blacklists than is
usual, so no help there either.
- His referer(sic) when he arrived was a google search for
"qzzp.futurenet.com.cn". When I tried this search it turned up an old
version of some Cliki page which had been spammed. Obviously, a
NOFOLLOW robots tag isn't enough to stop pages from already-followed
links continuing to appear in the index, and thus cliki continues to
appear to be a good place to spam. Even though as discussed
previously it won't get you any googlejuice.
So it was easy enough to add NOINDEX to the old pages as well. To make
robots take notice, though, I managed to touch every file on the site,
so the dates of previous revisions are a bit off (where 'a bit' is
between one hour and five years). But as of tomorrow evening
cvs.telent.net goes back online (I hope), which should make it
more convenient to hack on this, and in the process of adding diff
support I think I'll have to revamp the way that change information is
stored anyway, so keeping the dates of previous revisions in some
place other than the file's mtime should not be a tough additional
requirement.
I thought I'd try mucking around with some audio stuff#
Thu, 10 Mar 2005 02:45:26 +0000
I thought I'd try mucking around with some audio stuff. Chiefly I'd
like to be able to put mixes together for the FNS music bike; it
remains to be seen whether I actually can do this - or whether
anyone likes my (lack of) music taste - but first I needed software.
My findings, summarised and leaving out a lot of blind alleys:
- The Linux MP3-HOWTO is woefully out of date. Of the two
plausible-sounding apps it lists, emixer has disappeared from the
planet, and GDAM (a) doesn't build without some slight hacking up
GDAM_ARG_DOUBLE_ARRAY(arg).array[0] = spatial->##prefix##_x;
and (b) after fixing this, segfaults on starting due (I think) to some
problem with missing or incorrect XML files.
- Mixxx seems like it
ought to work, and even compiles (after installing a stack of
libraries that I've hitherto not had the need for, but fair enough).
But it needs a soundcard with a second output for cueing - although it
can be told to use Left for cue and Right for speakers, my motherboard
audio (VIA VT8237) allegedly can do six channels, so why not go for two
stereo outputs?
- (It also complains at startup about not having hardware GL, then
incessantly thereafter about GLXBadLargeRequest, but for the moment I
am choosing to deal with this by redirecting stderr. The claimed
workaround of disabling waveform display actually causes it to segfault)
- The ALSA fun starts here. With the aid of the motherboard manual
I figured that the microphone jack doubles as rear speaker output;
with a combination of amixer (which has a command-line
interface that actually lets you see what's going on, not some crappy
curses thing) and speaker-test -Dsurround40 -c4 I found
correct mixer settings to get front channels coming through speakers
and rear channels through the headphones plugged into the mic jack.
Look out especially for Spread Front to Surround and Center/LFE
and Surround Jack as Input, both of which should be disabled.
- This is the best ALSA
documentation I have ever read, and also the thing that gave me a
pointer to Using
surroundXX PCMs with JACK. With that and with
jackd -d alsa -S -d jack40 -n3 --inchannels 2 --outchannels 4
(less than 3 periods and I get enough "xrun" spewage that
xterm's scrolling shows up in top(1)) all that remains is to tell
mixxx's preference screeen to use alsapcm:playback[1234] in that
order for each channel it wants to send stuff down.
For my next trick I'm almost tempted to configure GL after all.
The video card (Voodoo 3 PCI) is old enough that it probably
ought to have Linux drivers by now, after all.
I thought it would be a simple hack when I started#
Thu, 17 Mar 2005 00:07:52 +0000
I thought it would be a simple hack when I started. It turns out it's
one of those jobs that if done properly will grow another dependency
every time you look at it.
In principle I am getting a new version of CLiki out of the door
that has John Wiseman's cliki diff stuff
in it. In the process I decide to upgrade to the latest
sb-unicode-enabled SBCL versions, and am having immense fun with character sets. Gah!
I have been muttering about SBCL runtime cleanups lately#
Thu, 24 Mar 2005 21:52:48 +0000
I have been muttering about SBCL runtime cleanups lately. Current thoughts
are
- smaller source files which do one (or a few) things each: e.g
vanilla-cheneygc-sigsegv-handler.c
- if defined(LISPFEATURESBTHREAD) && !defined (LISPFEATURESBPTHREAD)
- include "sigprocmask-pthread.c"
- endif
[...]
etc. As a general principle, though, #including *.c files gives me
the creeps, though, so it's more liekly we hack genesis to write out
something that make(1) can grok.
- target-features* at build time) then delete from it wherever we find
we built with support for a feature that's not present at runtime. I
think that Christophe has an arguably neater hack involving the
package system, though.
Depending on work workload, and on how long it takes to get acpi
suspend working properly on my new laptop (yes, I finally gave in -
it's a compaq nc4000; not quite as small as its predecessor but still
reasonably light), hope to see something along these lines early next
month.
Another laptop, another attempt at configuring outgoing email#
Tue, 29 Mar 2005 20:20:57 +0000
Another laptop, another attempt at configuring outgoing email. That
is, it's the same laptop as last week, but I'd been putting off this
task.
Requirements:
- Doesn't require me to stop using Gnus
- Works wherever I can find reasonable connectivity - does not
require me to be on a specific IP address or network, or able to send
SMTP directly to servers around the world.
- Can queue mail when I'm not connected to any such network.
- Reasonably secure: certainly nothing involving open relays
- Doesn't involve half a day learning about SASL or SMTP AUTH or
stuff like that
- Ideally, no need for lots of silly small scripts littering ~/bin/
Available: a shell host that I have ssh access to.
Solution: harness the awesome power of smtpmail.el
(require 'smtpmail)
(defun ssh-smtpmail-send-it ()
(let* ((smtpmail-smtp-server "localhost")
(smtpmail-smtp-service 2525)
(smtp-local-domain "telent.net")
(smtp-sendto-domain "telent.net")
(sendmail (start-process "ssh-smtp" nil
"/usr/bin/ssh"
"-L" "2525:localhost:25"
"loaclhost.telent.net"
"cat"))
(ready-p nil))
(labels ((filter (p s)
(if (string-match "tunnel is ready" s)
(setq ready-p t)
(message "Received from SSH connection: %s" s))))
(unwind-protect
(progn
(set-process-filter sendmail 'filter)
(process-send-string sendmail "tunnel is ready\n")
(while (not ready-p)
(accept-process-output sendmail))
(message "")
(smtpmail-send-it))
(process-send-eof sendmail) ; ask it nicely first
(kill-process sendmail))))); if that does nothing, inhume it forcefully(setq send-mail-function 'ssh-smtpmail-send-it)
(setq message-send-mail-function 'ssh-smtpmail-send-it)
Needs to be able to connect to the shell host (yes, really, it is
called loaclhost) without a password, which is what ssh-agent
was invented for. Needs no configuration changes on the shell host
(nor even root access, though it happens that I have that anyway).
How it works: (1) opens an ssh connection to the shell host and runs
cat, additionally with a tunnel connecting port 2525 on my laptop to
25(smtp) on the shell machine; (2) prints something to the cat process
and waits for it to come back - by this time the tunnel should also be
ready for use; (3) calls smtpmail-send-it, (4) cleans up. This is, I
feel, marginally less tacky than sleep n where
n is chosen experimentally to be (a) greater than the
connection/tunnel setup time, (b) less than would drive me mad while
waiting.
Incoming mail, if you were wondering, is delivered to a maildir on
loaclhost then synced with the notebook using maildirsync
In other laptop-related news: still can't get ACPI S3 suspend to
work. swsuspend2 doesn't like my pcmcia wireless card (it's an Atmel
thing). APM suspend does work, but running with no ACPI causes the
fan to spin constantly which is annoying in a quiet environment and
probably shortening battery life. But: I may be able to dispense with
the PCMCIA wireless card as I have a mini-pci card arriving tomorrow
from Solwise. It's not yet certain whether that will give me any
better PM support, but it can use the laptop's builtin antenna so
maybe it'll at least give me better reception. Will see. It would be
nice also if I can get it to distinguish more of the pointer buttons
from each other (four physical buttons but X only sees two) so that I
can have a proper middle button again.