Re: [ST-devel] autoconf and libst

[Wesley W. T. <we...@te...>]

On Tue, Dec 25, 2001 at 02:50:46PM -0800, Lev Walkin wrote:
> >MD_USE_SYSV/BSD_ANON_MMAP:
> >	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.

Ok, that doesn't rule out idea 1 though. Does MAP_ANON being defined
guarantee it is available and works?

Alternately, if build system == host system: run a check for sysv/bsd
semantics. If cross compiling fall back to idea 2 or malloc. (whichever is
better)

Again, what's wrong with malloc? I thought it uses mmap for large
allocations internally?

> >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.

Ok,

io.c:
static int st_nb_inherited = -1;

void st_determine_if_nb_inherit(int fd)
{
	long flags = fcntl(fd, F_GETFL);
	if ((flags & O_NONBLOCK) != 0)
		st_nb_inherited = 1;
	else
		st_nb_inherited = 0;
}

...
// code using #ifdef now:
if (st_nb_inherited == -1) st_derermine_if_nb_inherit(sock);
if (st_nb_inherited) _st_newfd_new(sock, 0, 1);
else                 _st_newfd_new(sock, 1, 1);
...
EOF

This should address the performance issue...?

> >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.

Hrm. Ok then, which OSs need serialized accept?

One last thing: I have it using poll() whenever the function is available
since I am under the belief that poll() is faster than select() - is this
wrong?

Thanks!

-- 
Wesley W. Terpstra <we...@te...>