I'm thinking of trying to push out a 1.6 release sometime this week. Things seem relatively stable, and we have some features implemented since 1.5.1 that are, I think, significant enough to merit a bump to 1.6 instead of 1.5.2. Specifically, we support external manipulation of the qthread library (e.g. external pthreads can block on qthread synchronization functions) and we also have a nascent ability to handle blocking system calls (like select() and read()). On top of that, I changed how we handle external interfaces like the Chapel compiler's tasking runtime interface.
Does anyone have objections to this plan?
--
Kyle B. Wheeler
Dept. 1423: Scalable System Software
Sandia National Laboratories
505-844-0394
Allan
First, the qthread_incr() and qthread_cas() functions weren't returning 64-bit values, and weren't passing in 64-bit values, so some of the logic was getting bolluxed up. I've fixed that in all but the most extreme cases (like PowerPC32), so that's good to go.
Second, there appears to be a problem with the fastcontext stuff on 32-bit x86; I'm not sure exactly what the problem is yet, but the %esi register seems to be getting corrupted somehow (so it only shows up when the compiler is being extra clever about the use of registers). Disabling fastcontext (which cannot be done on MacOS, for obvious reasons) seems to work around the problem. Unfortunately, this is some of the most delicate code in qthreads, so it may take a little bit of time to fix it.
I tend to think this is significant enough to delay 1.6, but I'm open to the idea that most people don't/won't care. Thoughts?