Le 27/07/2017 à 16:18, Enrico Weigelt, metux IT consult a écrit :
> On 27.07.2017 08:22, Didier Kryn wrote:
>
>> At first glance at least, it means that file offsets are managed in the
>> kernel or VFS
>
> Of course they are. That's required for any sane multiprocessing
> implementation. And some files/devices don't even have the notion
> of a current position (IOW: not seekable at all).
>
> > but they can be bypassed by pwrite(). AFAIR pwrite()
>> doesn't change the "current" file offset; it simply ignores and bypasses
>> it, which isn't exactly what your example does.
>
> Yes, that's an separate syscall for direct access. Simple streams
> (eg. tty's, pipes, stream sockets, etc) usually don't support it.
>
>> Using unistd's read() and write() in C means you are dealing with low
>> level issues; otherwise why would you bother with the complexity it
>> introduces - not only you need to deal with buffering but also with
>> retries when interrupted by signals.
>
> Usually you wanna care about signals - they actually mean something.
> The ansi stream functions might or might not make it easier - depending
> on your actual usecase. If you care about performance, you likely
> don't wanna use them.
In an ideal word, software would have
- maximum performance
- minimum resource usage
- minimum of dangerous bugs
- easy maintainability
- fast development
- what else?
It's impossible to reach all these targets in the same time;
therefore the first design decision is which compromise between these is
the target. This implies choices in the organization of the program, the
language(s) to use, and possibly the programmer(s). I'm sure you know
this very well :-)
Didier
::
Re: [DNG] High level language primi…
