Re: Library functions vs System calls

• Previous message: David Schwartz: "Re: Library functions vs System calls"
• In reply to: David Schwartz: "Re: Library functions vs System calls"
• Next in thread: David Schwartz: "Re: Library functions vs System calls"
• Reply: David Schwartz: "Re: Library functions vs System calls"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Thu, 14 Apr 2005 23:37:50 +0200

In comp.os.linux.development.system David Schwartz <davids@webmaster.com> wrote:
>
> "Grant Edwards" <grante@visi.com> wrote in message
> news:115t011clj7kaa@corp.supernews.com...
>
> > I've been writing Unix programs for 20+ years, and have never
> > once written code that made a system call.

Neither have I. Not in raw form!

> That's impressive, actually. In 20 years, you've never encountered the
> following situations:
>
> 1) You need to build a program on version X of an OS so that you can
> support version X and later.

Incomprehensible. What does "build ... so that you can support .." mean?
Building and supporting are two different thngs! Has some of that
sentence gone missing?

Maybe you mean "build in such a way that it can run under vX and later
of the o/s".

Uh - one does that by dynamic linking against libc. Let the library
maintainers look after backward compatibility (as our now will be when
the future comes round).

> 2) There's a system call available on version Y of the OS (Y>X) that you
> need to call on version Y and later (or that provides you some significant
> benefit on version Y and later).

One doesn't call system calls directly. If one does, one learns why not
through stuff exactly like that.

> 3) The library on version X does not include any wrapper for this system
> call because the call does not exist on version X.

One writes to libraries, not to system calls.

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

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 ªt the
best of times, and doing it with a dependence on stuff you don't control
is just crazy.

> 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?)

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

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

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

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

> 2) The wrapper has some crazy brain damage that absolutely boggles your
> mind as to its purpose.

Situation normal.

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

Peter

• Previous message: David Schwartz: "Re: Library functions vs System calls"
• In reply to: David Schwartz: "Re: Library functions vs System calls"
• Next in thread: David Schwartz: "Re: Library functions vs System calls"
• Reply: David Schwartz: "Re: Library functions vs System calls"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]