Solaris nitpicks

SDL Development
1

Hello,

I have a few minor issues with SDL 1.2.2 on Solaris.

I used Sun’s compiler and everything went fine except 64-bit data type.
SDL_types.h has a rather poor way of detecting if it’s available and the
method failed, because this compiler wasn’t listed. It would be better if
configure script:

  1. checked if <inttypes.h> header is available on the system
  2. if so, check if int_least64_t and uint_least64_t are defined
    3. if so, those types are exactly what’s needed
    4. if there are no *_least64_t types, check for int64_t and uint64_t
    5. if they exist, they can hold at least 64 bits, but might be
    larger, so use them if they are exactly 64-bits wide.

Those types are defined by C99 and a growing number of systems has them
defined these days. Using them would also enable having 32-bit and 64-bit
SDL library on the same system, but with the same header file.

SDL_x11image.c has a function num_CPU() which tries to determine number of
processors from kstat structures. The code mostly works, but it would be
somewhat simpler to replace it with:

sysconf(_SC_NPROCESSORS_ONLN)

Something very close is being done if USLC symbol is defined, but I
don’t know what’s being identified by it. It’s usually not defined by
compilers on Solaris.

The linking method has a small problem. “sdl-config --libs” outputs only
-lpthread. This is enough to make things work, but there’s one case when
it won’t give the expected results. Solaris 8 has two thread
implementations. The one which lives in /usr/lib implements userland
threads on top of a smaller number of kernel threads. Since Solaris
scheduler is not the best of its kind, in some cases it might be better if
applications used the implementation in /usr/lib/lwp, which has 1:1
mapping, smaller overhead and no problems with the scheduler.

The normal way to link programs against that implementation is to specify
-R/usr/lib/lwp when linking. However, that method would still pick
/usr/lib/libthread.so if the linking line specifies only -lpthread.
To make it work as intended, one must specify “-lpthread -lthread”, in
that order. So sdl-config should output both. And it would be nice if
libsdl was also linked against those libraries, although this is not
necessary.–
.-. .-. I will always cherish the initial misconceptions I had
(_ \ / _) about you.
|
| @Drazen_Kacar

2

Drazen Kacar wrote:

I used Sun’s compiler and everything went fine except 64-bit data type.
SDL_types.h has a rather poor way of detecting if it’s available and the
method failed, because this compiler wasn’t listed.

yes that code is a smelly heap of dung. I thought I had band-aided it for
the WorkShop compiler; I’ll look at it when I can

  1. checked if <inttypes.h> header is available on the system
  2. if so, check if int_least64_t and uint_least64_t are defined
    3. if so, those types are exactly what’s needed
    4. if there are no *_least64_t types, check for int64_t and uint64_t
    5. if they exist, they can hold at least 64 bits, but might be
    larger, so use them if they are exactly 64-bits wide.

while we’ll probably use the configure script to find a 64-bit data
type the above is an overkill — we need a type exact 64 bit or none
at all. Nothing for 1.2 at any rate

Those types are defined by C99 and a growing number of systems has them
defined these days. Using them would also enable having 32-bit and 64-bit
SDL library on the same system, but with the same header file.

That should be possible to arrange anyway. I’ll have a look

SDL_x11image.c has a function num_CPU() which tries to determine number of
processors from kstat structures. The code mostly works, but it would be
somewhat simpler to replace it with:

sysconf(_SC_NPROCESSORS_ONLN)

“mostly works”, meaning that it sometimes does not. Please be more
specific. I’ll be happy to replace if with the sysconf() if you can
verify its availability for Solaris 2.5.1 and onwards

Something very close is being done if USLC symbol is defined, but I
don’t know what’s being identified by it. It’s usually not defined by
compilers on Solaris.

I don’t know where that comes from. Sam, do you remember?

The linking method has a small problem. “sdl-config --libs” outputs only
-lpthread. This is enough to make things work, but there’s one case when
it won’t give the expected results

the 1:1 thread lib is new in sol 8 and I didn’t want to special-case
for it. When does it not give expected results? I’m not sure what
faults in the Solaris scheduler you are referring to, but shouldn’t
it be enough to request the threads to be bound?

Thanks for your comments though, I’ll look at it when I get better
(damn cold)

3

Drazen Kacar wrote:

  1. You are checking for the number of processors phisically present.
    The above sysconf() call would check for the number of processors which
    are on-line, ie. the number of processors that any application can
    actually use.

right you are, I’ll change it to use the sysconf (not that it is likely
to matter in practice)

(I have yet to find any reliable docs for the kstats. I suppose I’ll have
to glean at the kernel sources)

Most of the time, but then the effect you are getting is as if you’re
using 1:1 library with some overhead, so I’d like to get rid of the
overhead.

but when is the normal n:m thread implementation a problem? I’ve found
bugs in it but nothing related to that

Is it perhaps bugid 4288299 (Recursive mutexes are not properly released)?
That one has been fixed for Solaris 7 and 8 and patches are available.

this is a policy problem - ideally SDL should not assume any particular
OS version number (or patchlevel, same thing) as long as there is
a reasonable workaround for bugs in the environment. I’m not sure to
what extent the borken recursive mutexen affect SDL’s internals
(event locks etc)

(I wouldn’t mind leaving the recursiveness of SDL’s mutexen unspecified
for performance reasons)

4

Mattias Engdeg?rd wrote:

Sorry for the question mark above, my mail reader doesn’t have the best
I18N support.

Drazen Kacar <@Drazen_Kacar> wrote:

I used Sun’s compiler and everything went fine except 64-bit data type.
SDL_types.h has a rather poor way of detecting if it’s available and the
method failed, because this compiler wasn’t listed.

yes that code is a smelly heap of dung. I thought I had band-aided it for
the WorkShop compiler; I’ll look at it when I can

If you want to put a quick fix just for that compiler, the symbol it
defines is __SUNPRO_C.

  1. checked if <inttypes.h> header is available on the system
  2. if so, check if int_least64_t and uint_least64_t are defined
    3. if so, those types are exactly what’s needed
    4. if there are no *_least64_t types, check for int64_t and uint64_t
    5. if they exist, they can hold at least 64 bits, but might be
    larger, so use them if they are exactly 64-bits wide.

while we’ll probably use the configure script to find a 64-bit data
type the above is an overkill — we need a type exact 64 bit or none
at all. Nothing for 1.2 at any rate

It is an overkill, I agree. However, that’s what C99 and pre-C99
implementations call for. I’ve been told that there are systems which
don’t have 32-bit type among the basic types (char, short, int, long),
although they do have int32_t. I’ve never had access to one of those, so I
can’t verify from the first hand experience. And they are probably not
very important for SDL. So I don’t know.

Whenever I suggested checking for int64_t, somebody replied that C99
doesn’t make the existance of that type mandatory. Now I’ve sent the
description of the whole thing and I’m being told that it’s an overkill. :slight_smile:

SDL_x11image.c has a function num_CPU() which tries to determine number of
processors from kstat structures. The code mostly works, but it would be
somewhat simpler to replace it with:

sysconf(_SC_NPROCESSORS_ONLN)

“mostly works”, meaning that it sometimes does not. Please be more
specific.

There are two issues.

  1. You are checking for the number of processors phisically present.
    The above sysconf() call would check for the number of processors which
    are on-line, ie. the number of processors that any application can
    actually use. I suppose that’s the number you’re interested in. You
    could dig it up from kstat as well, though.

  2. Sun doesn’t guarantee binary compatibility for applications using
    libkstat. The API is stable, I think, but the names of the data
    structures are not guaranteed to be. Which means that you might be
    forced to #ifdef for a future version of the OS, just as you already
    have #ifdef for symbols which were changed between 2.5.1 and 2.6.

I’ll be happy to replace if with the sysconf() if you can verify its
availability for Solaris 2.5.1 and onwards

Currently I don’t have access to 2.5.1 system, but I can say that
sysconf() was working fine for me on 2.5.1, 2.6, 7 and 8 when I was working on
libgtop. And here’s the URL for Sun’s on-line sysconf() documentation for
Solaris 2.5 which lists the above symbol:

http://docs.sun.com:80/ab2/@LegacyPageView?toc=SUNWab_40_3:/safedir/space3/coll2/SUNWaman/toc/REFMAN3:1353_sysconf.3c;bt=man+Pages(3)%3A+Library+Routines;ps=ps/SUNWab_40_3/REFMAN3/1353_sysconf.3c

The URL could probably be shorter, but the man page is not reachable from
the browsing interface, so I had to use the search facility.

The linking method has a small problem. “sdl-config --libs” outputs only
-lpthread. This is enough to make things work, but there’s one case when
it won’t give the expected results

the 1:1 thread lib is new in sol 8 and I didn’t want to special-case
for it.

That’s perfectly fine, you shouldn’t because you are working on the
library. The application should be able to choose which thread library to
use. Or the user who is compiling the application.

When does it not give expected results? I’m not sure what
faults in the Solaris scheduler you are referring to, but shouldn’t
it be enough to request the threads to be bound?

Most of the time, but then the effect you are getting is as if you’re
using 1:1 library with some overhead, so I’d like to get rid of the
overhead. Besides, if you want to have bound threads on Solaris, then the
application has to #ifdef for Solaris. And if that can be avoided by using
alternate thread library implementation when linking, that course of
action should be available. (Admittedly, it doesn’t help if you’re on the
older OS release.)

The joke with libpthread and libthread is that libpthread is a filter for
libthread, ie. if you link with libpthread, run-time linker will load
libthread as well, because that’s where the code is. However, if you link
the application with -R/usr/lib/lwp, that search path will be used only
for direct dependencies of the executable, but not for their dependencies.
So you end up with using /usr/lib/libthread.so, although you intended to
use /usr/lib/lwp/libthread.so. The way to get around that is to also
specify -lthread when linking the application. That way libthread becomes
a direct dependency and search path for the application is honored when
ld.so.1 searches for it.

Thanks for your comments though, I’ll look at it when I get better
(damn cold)

There’s one more thing. Recursive mutexes are disabled by configure
script, because it thinks they don’t work on Solaris. I don’t know how
important is to have recursive mutexes in SDL and I don’t know which
problem you encountered.

Is it perhaps bugid 4288299 (Recursive mutexes are not properly released)?
That one has been fixed for Solaris 7 and 8 and patches are available.–
.-. .-. Errors have been made. Others will be blamed.
(_ \ / _)
|
| @Drazen_Kacar