2004-01-21 Morphable X Servers
xvfbtex showing the xgltex server mapped onto an animated
sinusoidal surface. Xterm shows ps output
Substantial tweaking has produced a version of xvfbtex
with full tracking of the textured X server's cursor by user control of
the pointer across the scene.
Basically this means that when you move the mouse across a scene of
objects, your path across the object with an X server framebuffer
textured across the side will be tracked by that X server's pointer.
Currently pointer tracking is a special case, and has not yet been
encapsulated in a form suitable for reuse, but that encapsulation will
provide, among other things, a straightforward approach to interactive
painting onto 3d surfaces.
2003-10 Ah, threads.
(Download
the threaded life project)
I knew that writing the classic life cellular automaton as a orgy of
gratuitous threads,
one per cell, plus threads for input and display,
would expose some limitations; that was the point. But I was surprised
to discover just how much misinformation is out there about limits on
the maximum number of threads in a process. So, to help anyone else
trying to run a few thousand threads in one program: the cumulative
stack size in all your threads is probably the problem. You can test
this as easily as using the ulimit shell builtin to reduce your
default stack size, and then seeing if suddenly your program can create
more threads than before. The same reduction can be coded using
pthread_attr_{get/set}stacksize().
With this method, I reduced the stack sizes for the cell threads in the
test code from 1 MB to 1 KB for all but 3 threads, and now it works
fine at 7103 threads instead of the earlier 234. The
file /proc/sys/kernel/threads-max on my machine contains the
value of 14336, suggesting a maximum of about twice what I'm seeing,
but I don't see a need for anywhere near even what my testcase is using
(although, I wonder if you could overlap the stacks if your threads
used no variables or function calls...hehe). Good luck :-)