CRiSP Weblog

What a nice machine!

I knew about the new Apple announcements today, and didn't think they could impress or surprise me.

The Apple mini is a gem - small in size, quiet (I hope), and cheap/affordable, especially as an 'extra' machine.

When I have browsed the net for new interesting machines, I see lots of nice subnotebooks, and anything stamped with SONY seems to be overpriced - a conscious buying decision.

But Apple have done something to trounce SONY and Microsoft - a cheap, powerful, machine with no operating system tax. As a spare file server, Mac/Unix server, or however you look at it, its a treat.

Now I just need to decide if I really need one (yet)!

Well I've played with the AXIM 50v for a few days and its really nice...

But Pocket IE is still pretty pathetic - its sluggish on a 624MHz ARM CPU. Like its Windows desktop cousin, its lacking in so many features its unbelievable. Things like being able to scale the fonts better than "Small, Smaller, Big, Bigger". Ability to turn off images would be good. Or the ability to switch landscape/portrait for this app only, rather than for all apps.

Thank heavens that Lister (see http://www.crisp.demon.co.uk for a copy) still works. It needs some slight reworking as I think of new features.

If you havent seen Lister, its a glorified "more" utilty for browsing text files, but it supports .html.gz files (although only a subset of HTML). I use this to download newsgroups and read on the move.

I need to get my scrabble game going for the odd journeys.

My AXIM came with two games - a car racing game which looks good but like all car games, I find incredibly boring. And a brain teaser app that looks nice but I havent gotten into it yet.

The wireless capabilities are very satisfactory at present - allowing me to browse the net from anywhere in the house.

Everything else looks typically Microsoft - looks nice but is definitely 'missing' something, (see IE above!).

The 640x480 screen means I can use smaller fonts and use the ClearType facility (which previously I would turn off), as it seems to work well on this screen.

I downloaded eVC++ 4.0 so I can rebuild Lister and the other tools, and it seems to work fine - especially as its free.

New toy to play with. Been wanting a new PDA with high res screen (640x480) though my eyes are not so good as they used to be. But it has built in wifi, so I can browse the internet at home.

Alas, blew up my old 1GB Microdrive trying to extract it from the old PDA. I put a 64MB spare flash card in the new PDA and its significantly faster than the old microdrive. Hadnt realised how slow that was.

And no, CRiSP isnt coming to a PDA near you. Mind you it did use to run on an old HP100LX (512KB RAM!). Once, and it took 20seconds to startup on a 12MHz 80286 (I think thats what it was).

Well its coming along fine. CRiSP is running (on Linux at least) multithreaded. (Well more, limping along!)

So far the challenges have been pretty straightforward - code cleanups, avoiding static/global vars so that the threads don't step on each others toes.

Mutual exclusion is a pain though. Linux/GCC provides recursive mutexes, which allow subroutines to apply locks and those routines to call sub-subroutines which increment the same locks. Unfortunately these locks are GNU extensions and not standard POSIX, which implies when the port is done to other OS's, chances are high I will be left high and dry.

Since I am aware of this I can cope/code for it, but I'm getting to the point where I need to track down more race conditions in the code.

I have a test macro which just runs a lot of primitives in the background. It misses a lot of issues which will need addressing, such as locks on buffers, GUI objects and other issues. For now I want to just concentrate on getting it running under duress.

Here's a pre-release of the thread mechanisms in case you want to see what it looks like:

# include	

void xx()
{	int	tid;
	int ret = pthread_create(tid, 0, "::thread", 0);
}
static void
thread(int arg)
{	int	i;
	int	zero;
	string	s;
	list	lst;

	for (i = 0; i < 10000000; i++) {
		message("%phello %d", i);
		int dh = opendir(".");
		remove("bye bye");

		while ((s = readdir(dh)) != "") {
			s += "hello-again";
			s = gsub("e", "", s);
//			re_search(SF_UNIX, "zzz\\z.*xxxxx.*");
			lst[0] = simplify_filename(s);
			open(s, O_RDONLY);
			switch (s) {
			  case 1:
			  case "x":
			  	break;
			  }
			}
		i += zero * sizeof(lst);
		closedir(dh);
		}
}

I've been playing with threads on Linux recently. Expecting Linux to have matured out of the kindergarten stage, but sadly, was disappointed to see it still throwing its food at the wall.

GNU C supports the "__thread" declaration specifier, which allows you to have a global variable which is unique on a per thread basis. This is nearly identical to Microsofts "declspec(thread)" syntax.

Except it doesn't work on earlier GCC releases. And requires an appropriate release of GLIBC. This means that with CRiSP support Linux GLIBC 2.1 and 2.2, we would have to potentially support 2.1+2.2+2.3 with/without proper working threads support.

Linux does have POSIX pthread support, so thats a start, but adapting a process to multithreadness using __thread is a very powerful option. The alternative is lots of source code modifications.

I took a look at Perl's source code to see how they do it, and it showed me the way to get maximum portability (passing a thread context structure from one function to the next). It too, does not rely on thread local storage. Its just messier and potentially a performance hit (size and speed).

I am disappointed that Linux thread local storage is so poor and cannot be relied on.

Happy new year