Re: Library functions vs System calls
From: David Schwartz (davids_at_webmaster.com)
Date: 04/15/05
- Next message: David Schwartz: "Re: require crypto API"
- Previous message: kernel.lover: "Re: require crypto API"
- In reply to: Peter T. Breuer: "Re: Library functions vs System calls"
- Next in thread: Peter T. Breuer: "Re: Library functions vs System calls"
- Reply: Peter T. Breuer: "Re: Library functions vs System calls"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 14 Apr 2005 22:38:49 -0700
"Peter T. Breuer" <ptb@lab.it.uc3m.es> wrote in message
news:ee43j2-jak.ln1@news.it.uc3m.es...
> 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?
You have to build on version X that you can support version X and later.
It's simple English. If you build on a version later than X, your code may
not run on version X. You may not be able to build on a version earlier than
X, so you build on X.
> Maybe you mean "build in such a way that it can run under vX and later
> of the o/s".
Yes.
> 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).
I agree. That is why one would do that, so that's what you do.
>> 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.
Huh? Yes, you do call system calls directly because in this case, you
*can't* do it through libc. You can either check if the call exists before
making it (with a version check) or look for an error "system call not
implemented, ENOSYS" when you make the call. Either way works fine.
>> 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.
No, one writes to a set of platforms. One uses the library where this
gives you what you need from the platforms.
>> 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?
> 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.
Sometimes you have to get the job done and sometimes the library gets in
the way. Like it or not, that's a fact.
>> 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
some functions as cancellations points? If you don't understand what I'm
talking about, why are you replying to it?
>> 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'?
>> 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?
>> 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.
>> 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?
>> 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.
DS
- Next message: David Schwartz: "Re: require crypto API"
- Previous message: kernel.lover: "Re: require crypto API"
- In reply to: Peter T. Breuer: "Re: Library functions vs System calls"
- Next in thread: Peter T. Breuer: "Re: Library functions vs System calls"
- Reply: Peter T. Breuer: "Re: Library functions vs System calls"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
