[lsb-discuss] LSB conf call notes for 2008-04-30

[Joseph Kowalski]

Jeff Licquia wrote:
> Java: Strategy.  Jeff: rumor on JVM use of syscall.  Mats: doesn't sound 
> right.  Ted: may be too good to be true.  Mats: also, there's a call to 
> find the glibc version; may not want to expose that.  Bug filed for that 
> call.
>   
...
> syscall.  gettid() and tcmalloc.  tcmalloc not an issue.  gettid() is 
> not in glibc, rejected by Ulrich.  Ted: Ulrich may want a generic 
> interface for the kind of information you can glean from /proc using the 
> result of gettid(); may not be a valid reason for rejection.
If its a rumor, perhaps you could share it with me?

I spent some time looking at what Mats posted (relevant to Java usage of
syscall).  I pretty much agree with what he said (after all, most of this
was from the comments in the sources).

However, I think the issues could be generalized to any, "interesting",
multi-threaded application.  (gettid and fork on 64-bits)
I have no clue as to why it appropriate to have a "gettid" manpage yet
not have the wrapper.  All this results in is the awkward use of
syscall(SYSgetti,...) rather than gettid(...).  Either its "private" (hence,
no manpage) or its public (should have a wrapper).  I don't see any
reason for being half-way.

I'd agree that having to fumble around via /proc isn't the cleanest or
most efficient way to access this information.  However, I'm not sure
that a "generic interface" is the way to go.  You really don't want
applications to depend upon all the interesting stuff /proc can tell
you.  /proc is "a lot of rope".

If you want, the original author of /proc works for Sun.  I suspect
that he has already talked to the Linux maintainers of /proc, but if
there are specific issues, I could ask him.

- jek3