I somehow got this idea into my head that if I wanted to properly track down the problem with pfinet, I should probably finish learning how the mach interface and threading system works (I've only used pthreads). I now have a couple thoughts/questions:
1) mig looks for the wrong compiler. I filed a bug against this. It also doesn't have a build-depends line - so I didn't file that it should have 'flex' added to the list. 2) My first glances at cthreads don't show much of a difference from pthreads. Would it be really bad to provide a shim to provide most of the common functions of pthreads simply as a wrapper to cthreads? It looks like it might be only 4 or 5 hours of work to get right (using the linuxthreads headerfiles). We could always #error out any functions too difficult to implement and maybe solve some of our porting difficulties. I saw some user-space implementations of cthreads on top of pthreads that could proably provide some information. 3) Apparently we do some things differently with mig than the CMU folks did. =) I'm trying to write a simple client server type of thing that can do two things: o Request a single int from the server (probably the result of i++ or something like that) o Send a request to shutdown. When I have figured this out, I will post it on the Hurd web site for anyone to look at. 4) When I was having some trouble, I decided to try running my code through g++ instead of gcc. I do this because sometimes I get better error reporting out of g++. This eventually led me to try and compile a new dpkg. Native gcc reports itself as i386-unknown-gnu0.2, which isn't in the archtable. Should I report this as a bug? I don't want to step on any political toes (I'll wait until my Debian application is approved for that... <Grin>) That, and I learned to make Sushi this evening.. But that's probably for a different list. =) Bed time. -- Anyone who sais "Sticks and stones may break my bones but words will never hurt me" has never had a dictionary thrown at him.
