Re: [ST-devel] autoconf and libst

[Lev W. <vl...@ne...>]

> MD_STACK_GROWS_UP/DOWN:
> 
> 	I can't see how to detect this during configure without breaking
> cross-compilation. To work with cross-compiling you'd have to somehow fail
> to compile if it is STACK_GROWS_DOWN. It's easy enough to detect this at
> runtime anyways, and it's only in one file: stk.c and called at thread
> creation time. Hence I assume the cost to speed is not important?


Thread creation is very complicated task relative to other st
activities. Run-time dectection seems to not made things noticeably
worse.

> MD_USE_SYSV/BSD_ANON_MMAP:
> 
> 	I have a couple ideas how to deal with this.
> 	Idea 1:
> #ifdef MAP_ANON
> do BSD stuff
> #els
> do SYSV stuff
> #endif
> 
> 	Idea 2:
> always open /dev/zero
> #ifdef MAP_ANON
> flags |= MAP_ANON;
> #endif
> mmap


It is a bad idea to invoke useless open() call with mmap(), if we
can avoid it.

> 	I don't know enough about mmap to know whether these would work
> however. -- PS. What's wrong with malloc?



> MD_ACCEPT_NB_INHERITED:
> 
> 	Why not just assume it's not inherited and always reset the thing
> nonblocking? Is it really such a performance hit?


System call is always a performance hit. But related with other
types of activities during thread initialization, it is almost nothing.


> MD_ALWAYS_UNSERIALIZED_ACCEPT:
> 
> 	I don't know enough about this to write a test. Could someone give
> me a hand?


Actually, it is somewhat hard to write a multiprocess test of such
a nature within automake framework. You should consider using internal
__OS_Type__ variables in header or code files to protect this place.


> MD_SETJMP/MD_LONGJMP:
> 	
> 	I am presently running this order of tests:
> 	if __ia64__ defined, use _ia64_cxt_* and include the assembly file.
> 	if setjmp available, use it
> 	if _setjmp available, use it
> 	fail with an error
> 
> 	PS what's wrong with setjmp/longjmp for ia64?
> 
> MD_GET_UTIME:
> 
> 	Test for these functions:
> 	read_real_time time_base_to_time gettimeofday
> 	syssgi clock_gettime gethrtime ftime
> 
> 	Use them in this order:
> 	gettimeofday
> 	read_real_time & time_base_to_time
> 	syssgi & clock_gettime
> 	gethrtime
> 	ftime
> 	fail with an error
> 
> MD_INIT_CONTEXT:
> 
> 	I have no idea how to check for this one. If I were willing to give
> up cross-compilation I would simply write a test which tried each and use
> the one which doesn't crash. :-) However, I would rather not... The other
> option would be to examine the target machine's name and have a big lookup
> table for each machine. I am guessing this define is why the current 'make
> target' exists.
> 
> So, to summarize: I have it mostly autoconf/automake/libtool/rpm/deb'd up.
> As soon as I get some idea as to how to tackle MD_INIT_CONTEXT and the
> SERIALIZED_ACCEPT, I'll put together a tar.gz to be perused by you folks.
> 
> If I don't hear back from anybody, I'm going to assume that the order I
> check for things will work, always use serialized accept, and use a lookup
> based approach to MD_INIT_CONTEXT.
> 
> Hope to hear back from you guys!
> 
> 



-- 
Lev Walkin
vl...@ne...