What is the difference between system call and function call. Is fopen a system call or function call.
fopen
is a function call, but it may sometimes be referred to as a system call because it is ultimately handled by the "system" (the OS). fopen
is built into the C runtime library.
fopen is a function call.
A system call interacts with the underlying OS, which manages resources. Its orders of magnitud more expensive than a function call, because many steps have to be taken to preserve the state of the process that made the syscall.
On *nix systems, fopen wraps open, which makes the system call (open is the C - wrapper for the syscall). The same happens with fread /read, fwrite / write , etc..
Here there's a nice description of the tasks executed by a unix syscall.
A system call is a call into kernel code, typically performed by executing an interrupt. The interrupt causes the kernel to take over and perform the requested action, then hands control back to the application. This context switching is the reason that system calls are slower to execute than an equivalent application-level function.
fopen
is a function from the C library that, internally, performs one or more system calls. Generally, as a C programmer, you rarely need to use system calls because the C library wraps them for you.
System call actually calls out to an API executed by the kernel space. With all the associated costs this assumes (see Wiki, or this link for details)
A function call is a call to a piece of code in user space.
However, please note that a function call MIGHT be to a function which in the process of its execution does system calls - "fopen" being one of such examples. So while the call to fopen itself is a call to a function, doesn't mean that the system call will not happen to handle the actual IO.
A point of view to add to this discussion is that a function call generally in the most optimistic case has overhead of a a few 8-bit instructions (4-10 on average)in x86.
A system call has the following properties.
- It Executes far more instructions, it has to freeze a process instead of simply the stack state.
- The timing involved is mostly non-deterministic.
- It is often a scheduling spot, and the scheduler may choose to reschedule.
For these three primitive reasons (there are probably more), one should reduce the amount of system calls where possible -- e.g., networked system software keeps socket handles (and other application specific internal data structures used by a connection) around to assign to new connection, why bother the kernel ?
Remember that software is built like a upside down pyramid. System calls are at the base.
Just to complete the picture presented by the others, fopen
is commonly implemented as a wrapper around open
, which is also a user-accessible function. fopen
is, in a sense, higher-level than open
since the FILE*
structure it returns encapsulates stuff for the user. Some users use open
directly for special needs. Therefore it wouldn't be right to call fopen
a "system call" in any way. Nor does it execute system calls directly, since open
is also a function callable by the user.
If you're using Linux you can monitor system calls performed by an application:
strace appname ...
Its output might give you a good insight on what's going on within libc, and which functions are actually system calls.