Re: Library functions vs System calls

From: Peter T. Breuer (ptb_at_lab.it.uc3m.es)
Date: 04/15/05 

Date: Fri, 15 Apr 2005 08:07:32 +0200

In comp.os.linux.development.system David Schwartz <davids@webmaster.com> wrote:
> "Peter T. Breuer" <ptb@lab.it.uc3m.es> wrote in message news:ee43j2-jak.ln1@news.it.uc3m.es...
> > One doesn't call system calls directly. If one does, one learns why not
> > through stuff exactly like that.
>
> Huh? Yes, you do call system calls directly because in this case, you
> *can't* do it through libc.

Then don't do it (by "libc" I assume you mean "libc and whatever other
set of libraries there are, such as libsvga, that provide a standard and
portable api to the set of system functions you are interested in").

> You can either check if the call exists before
> making it (with a version check) or look for an error "system call not

Simply do not call a system call. That is none of an applications
business. Leave it to a library (if you were to say "ioctl" I might be
more sympathetic to your problem, but system call? No!).

> implemented, ENOSYS" when you make the call. Either way works fine.

"Don't do that" works better, and is extremely portable.

> > One writes to libraries, not to system calls.
>
> No, one writes to a set of platforms. One uses the library where this
> gives you what you need from the platforms.

No, the libraries provide the platform to the application. It's a clear
and fundamental separation of applications from API from o/s.

> >> 1) You're writing a program that needs to invoke system call X a lot.
> >
> > One isn't. One doesn't. It's none of ones business.
>
> What?

Exactly.

> > How the system (and I include its libraries) does what it does is the
> > business of the system designers. Yours to use. That's what
> > maintainability and portability means. Optimization is ungood at the
> > best of times, and doing it with a dependence on stuff you don't control
> > is just crazy.
>
> Sometimes you have to get the job done and sometimes the library gets in
> the way. Like it or not, that's a fact.

No, it's a missed opportunity to LART the library author with your
concerns and help him develop it in a direction that helps both of you.

> >> 2) The function for system call X is defined as a thread cancellation
> >> point.
> >
> > Umm. Technobabble. (I shudder to think of what you might mean, though!
> > Does posix really define threads as only having certain synchronization
> > points?)
>
> Huh? Do you know what a cancellation point is and that POSIX defines

I have not the faintest idea what you mean by that jargon pair (I said
"technobabble", no?). If you care to express yourself in comprehensible
english I am sure I will understand you just fine. Do you mean a point
at which a hread may be terminated? What then?

> some functions as cancellations points?

I have no idea what jargon words POSIX uses (nor terribly much
interest) for otherwise ordinary and comprehensible concepts.

> If you don't understand what I'm
> talking about, why are you replying to it?

In the hope that you may take the opportunity to express yourself less
obfuscatedly.

> >> 3) The check for a pending cancellation is fairly expensive and your
> >> program doesn't use cancellation anyway.
> >
> > None of our business. Use an algorithm that Does Not Do That Call Then.
>
> How can you not call 'read'? Or 'connect'?

Use one that does it less often, does it in multiples of blocksize, and
uses aligned buffers. Also speculative read combined with a
thread-common database of read statuses might be useful, or not.

> >> 1) You want to call a function from a signal handler.
> >
> > One does not call anything from a signal handler - just set a flag and
> > let a regular service routine pick up on the flag.
>
> Why are you arguing with the hypothetical? Are you saying there are
> never reasons to call functions from signal handlers?

Sure - the desire not to run a separate thread to service the detected
signals. Whether that's a supportable desire or not depends on the
circumstances. But usually there will be some parent thread that just
sits around happily watching its children play and which can be copted
into running an interrupt service routine in a loop, while its children
just flag the received signals for it.

> >> 2) The library wrapper for that function calls functions that aren't
> >> safe to call from a signal handler's context.
> >
> > Well, now you definitely know why not to call anything from a signal
> > handler.
>
> Umm, but there's a simple workaround.

Which you do not want to apply. Same reason as you do not want to
optimize very far - maintainability.

> >> 1) You want to call a function that is a wrapper around a system
> >> call.
> >
> > None of our business how the function is implemented. If we don't
> > like its performance, use a different one, but personally, I'd welcome
> > the chance to bother The Author about it.
>
> This is a hypothetical. It happens a lot that you want to call functions
> that are wrappers around system calls. Why are you arguing with an obviously
> often-true hypothetical?

Shrug. "read" is such a wrapper if you want to put it like that. I
would rather think of whatever system call read calls (sys_read, of
course) in the kernel as being there to provide the appropriate support
to the libc API function "read". Not the other way round. We program to
the API, not to the support for the API.

> >> 2) The wrapper has some crazy brain damage that absolutely boggles
> >> your mind as to its purpose.
> >
> > Situation normal.
>
> Sometimes, but sometimes it's disastrous.
>
> >> These are four situations I've encountered in my mere 10 years of UNIX
> >> development. In each case, the solution was to invoke the system call
> >> directly. The first one is, IMO, the most common.
>
> It seems like you just want to argue for no sensible reason.

I just take issue with the claim. I also have never called a system call
directly - an ioctl yes, a system call no. There aren't so many system
calls (how many? 200?) that I can imagine there not being a suitable API
handy, and I similarly cannot imagine anyone implementing an system
call UNLESS there were an API for it to support.

Peter

Relevant Pages

  • Re: Library functions vs System calls
    ... portable api to the set of system functions you are interested in"). ... the libraries provide the platform to the application. ... It's none of ones business. ... not to the support for the API. ...
    (comp.os.linux.development.system)
  • Re: Library design for canceling a running operation?
    ... "heavyweight" threading code to support the async part of this api. ... How would having an async api solve this issue when the implementation would internally create a thread for every operation. ... I highly doubt that there will even be an application that will want to support concurrent transfers. ... The net effect of dealing with libraries that have weird threading ...
    (comp.programming.threads)
  • Re: PolyORB - building and applications
    ... If you qualify for the GAP program, you will get good support from AdaCore ... version with support - I use Ada software to run my business. ... It might take a month to rewrite code to avoid suspected libraries. ...
    (comp.lang.ada)
  • Re: zip compression component
    ... If you have the full VS installed, there is actually zip support in the J# ... libraries (well, it is supposed to support everything that could be done ... within c# as they are standard .NET assemblies. ... > know if there is an API for accessing the built-in compression in windows? ...
    (microsoft.public.dotnet.framework)
  • anyone? algos for calculating good contact info for solids
    ... physics engine for a 3d engine project of mine (some things have not been ... it uses a somewhat opengl-influenced api. ... begin/end pairs, properties, vertices, and normals is used. ... an odity of mine to try to seperate these from "utility" libraries. ...
    (comp.graphics.algorithms)
Loading