On Tue, Oct 26, 2004 at 09:19:44AM +0200, Maurice van der Pot wrote:
> On Tue, Oct 26, 2004 at 11:17:28AM +0900, Stephen J. Turnbull wrote:
> > >>>>> "Jan" == Jan Harkes <jaharkes_at_cs.cmu.edu> writes:
> > 
> >     Jan> But after thinking things through it really doesn't matter
> >     Jan> whether we fork before or after LWP threads have started
> >     Jan> since they are not kernel threads.
> > 
> > This would however complicate an eventual move to kernel threads, no?
> > 
> > ISTR some discussion of that, but I don't recall whether the
> > conclusion was "yes, eventually" or "You Aren't Gonna Need It" (YAGNI).
> 
> While we're on the subject of LWP and threads... (I'll just hijack my 
> own thread here if you don't mind ;) ), I have noticed a while ago that
> glibc compiled with 2.6 kernel headers and gcc 3.4.x + coda is a bad 
> combination. You can read all about it in a bug report that I submitted: 
> http://bugs.gentoo.org/show_bug.cgi?id=58702
> 
> I'm not certain if you can use this information, but I wanted to make 
> sure you are aware of it. Just in case you get bug reports about it.

I wasn't aware of the problem. You could bump the lockqueue manager
stacksize, to 16KB or more and see if that avoids the problem.

coda-src/vol/lockqueue.cc:45
- const int  LockQueManStkSize = 8192;
+ const int  LockQueManStkSize = 16384;

Looking at the source for _IO_vfprintf, this could be the difference
between wchar_t and char_t. wchar could be 16-bits, but more likely an
int. There is a CHAR_T workbuffer[1000] which would be about 8KB if
wchar is defined as an integer.

The kernel headers only define wchar in linux/nls.h, and it is a 16-bit
value. It looks like gcc-3.3 stddef.h defines __WCHAR_TYPE__ as an
integer.

Jan