Re: [ST-devel] autoconf and libst

[Mike A. <mj...@at...>]

[I missed the original post on this subject due to @Home cratering and
the list archive seems not to work, so sorry for the late reply.]

I applaud attempts to simplify and proliferate state threads but I have
doubts about the need for throwing autoconf into the mix.  For a large
and complex project autoconf has merit but for a tiny little library
like state threads it's overkill.  The machine-dependent definitions in
md.h take only a couple dozen lines each and the set of variables that
needs to be researched and defined to add new systems is small enough
that doing it manually is not arduous.  I'm not sure but isn't autoconf
itself larger than the whole st library?

Recent mail on this list about the auto-building subject ask questions
like "is adding a single system call to thread creation really a bad
thing?" and the like.  The answer is an unqualified yes, it is horrible.
The introductory paper says:

	3.3 Performance

	Performance is one of the library's main objectives.
	The State Threads library is implemented to minimize the
	number of system calls and to make thread creation and
	context switching as fast as possible. ...

	(http://state-threads.sourceforge.net/docs/st.html)

On the other hand I welcome packaging efforts.  Casual users frown on
having to compile software so providing rpms, srpms, and other popular
package formats will expand the project's audience.

Now to answer some specific questions:

> MD_ACCEPT_NB_INHERITED:
> Is it really such a performance hit?

Yes.

> MD_GET_UTIME:
> 	Use them in this order:
> 	gettimeofday
> 	read_real_time & time_base_to_time
> 	syssgi & clock_gettime
> 	gethrtime
> 	ftime
> 	fail with an error

If you intend to probe for these functions in this order and to use the
first match your performance will suffer.  clock_gettime on SGI systems
is a memory load not a system call and is therefore much faster than
gettimeofday.  I assume gethrtime is similar.  gettimeofday should be
the last resort.

> You should consider using internal
> __OS_Type__ variables in header or code files to protect this place.

Ugh, I strongly prefer the current scheme in md.h.  All the
system-dependent definitions are in one place rather than scattered
about.

> Who is the official upstream maintainer?

Please define this term.  Gene and I are the ultimate owners of the
project.  I don't think sourceforge provides a "state-threads-owner"
mail alias so snarf our sourceforge addresses from the project summary
page.

> poll() is faster than select() - is this wrong?

In addition to the other analysis offered of relative speed, select has
the feature that multiple threads waiting for the same fd don't change
the system call.  With poll, each waiting thread has its own pollfd even
if all of the fds are the same.  So the right choice (poll vs. select)
depends on not only the total number of fds but also their expected use.