diary at Telent Netowrks

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

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:

  1. 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.

  2. 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?

  3. (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)

  4. 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.

  5. 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

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:

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.

⟪Feb 2005 Apr 2005⟫