Lecture 6

Carnegie Mellon
Processes, threads and their scheduling

N. Navet - Computing Infrastructure 1 / Lecture 6
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 1

Carnegie Mellon
Processes, threads and their scheduling

 Processes
 Context Switches
 The different states of a process
 Creation of process
 Termination of a process
 Loading and executing binary files
 The scheduler and the dispatcher of the OS
 Examples of scheduling policies
 Threads vs processes
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition [edited NN] 2
Carnegie Mellon
PROCESS: A KEY ABSTRACTION

PROVIDED BY THE OS

Carnegie Mellon
Preamble - Flow of Control

 Processors do only one thing:
▪ From startup to shutdown, a CPU simply reads and executes
(interprets) a sequence of instructions, one at a time
▪ This sequence is the CPU’s control flow, it is the sequence of the
Program Counter’s values.
CPU aka physical control flow
<startup> The CPU control flow is
inst1 comprised of the control
inst2 flows of the different
Time processes/interrupts
inst3 which are interleaved
…
instn
<shutdown>

Carnegie Mellon
Processes
 Definition: A process is an instance of a program (in
binary format) that is executing
▪ Not the same as “program”: there can be several instances of
the same program running
Memory
 Two key properties ensured by the OS: Stack
Heap
Data
▪ “Logical” control flow Code
Each process seems to have exclusive use of the CPU incl.
▪
its registers CPU
▪ Virtual memory Registers
▪ Each process seems to have exclusive use of main
memory.

Carnegie Mellon
Concurrent processes, multitasking &

preemption We assume here a single computational unit
executes
These 3 processes are said to run concurrently
Each process executes for some time and then is preempted (=temporarily
suspended) while other processes take their turns (multitasking). Each process
seems to have exclusive use of the processor.

Carnegie Mellon
Computers run many processes simultaneously
 Running program “top” on Unix-like OS (here Mac OS)

▪ System has 123 processes, 5 of which are executing, others are
blocked or “sleeping”
▪ Processes are identified by Process ID (PID)

Carnegie Mellon
Switching from one process to another: saving &

restoring process context upon context switches
Memory
Stack Stack Stack
Heap Heap Heap
Data Data … Data
Code Code Code
Saved Saved Saved
registers registers registers
 When the OS decides to transfer control to another

CPU process, it performs a context switch:
Registers ▪ Before switching to the selected process (which is selected
according to scheduling policy and states of the processes):
save current registers in memory (within the OS kernel)
▪ Before transferring the flow of control to the newly
selected process: restore saved registers (if the process has
already been executed before), and switch to the virtual
address space of the process that executes next
Carnegie Mellon
What is the impact of

Context Switching multitasking on caches?
 Processes are managed the kernel of the OS
 Control flow passes from one process to another via a
context switch Process A Process B
user code
kernel code context switch

Time user code
kernel code context switch
user code
Cache pollution: when a process resumes after a context

switch, all memory blocks it uses (data+code) may have been
evicted and the cache must be populated again – the code
execution time will then increase because of successive cache
misses. The same happens when interrupts occur.
Carnegie Mellon
PROCESS CONTROL:
THE ROLE OF THE OS

Carnegie Mellon
Process Management Activities
The OS is responsible for the following tasks:
 Creating and terminating both user and system processes

 Suspending and resuming processes
 Providing mechanisms for process synchronization (e.g.,
when they need to access shared resources)
 Providing mechanisms for inter-process communication

Carnegie Mellon
Process States (1)

The three states a (non-terminated) process can be in:
1. Running: actually using the CPU at that instant
2. Ready (runnable): temporarily on halt to let another
process run
3. Blocked: unable to run until some external event happens
Tanenbaum & Bos, Modern Operating Systems: 4th ed., Global Edition (c) 2015 Pearson Education Limited. All
rightsandreserved.
Bryant O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 13
Carnegie Mellon
Process States (2)
Process creation
A process can be in running, blocked, or ready state (default state

upon creation). Transitions between these states are as shown.
Next: process termination & process creation

Carnegie Mellon
Process Termination
Conditions which terminate a process:
1. Normal exit (voluntary):
• Returning from the main() routine
• Calling the exit() function (a system call) without an error
code (convention: normal return status is 0, nonzero on
error)
2. Error exit (voluntary)
• Calling the exit() function with error code
3. Fatal exception error (involuntary): illegal instruction (e.g.
versus execution mode), division by zero, etc
4. Killed by another process (involuntary from killed process’
perspective).
rightsandreserved.
Bryant O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 15
Carnegie Mellon
Process Creation
When are processes created ?
1. System initialization: e.g., on Unix the first system process init
(systemd in Linux) loads other daemons like cron, sshd
2. Execution by a running process of a system call to create
another process : e.g., creation of a process in a command
shell by the user entering a command Our focus
In UNIX, there is only one system call to create a new process: fork. This
call creates an exact clone of the calling process – except that parent’s
and child’s process have different PIDs
Nb: process creation is slightly different under Windows but same principles apply

Carnegie Mellon
Creating Processes
 Parent process creates a new running child
process by calling fork()function
 fork is confusing because it is called once but returns
twice ! Once in the calling process, and once in the newly
created child process
 int fork(void)
▪ Returns 0 to the child process, child’s PID to parent process
▪ Child is almost identical to parent:
▪ Child get an identical (but separate) copy of the parent’s virtual
address space.
▪ Child gets identical copies of the parent’s open file descriptors
▪ Child has a different PID than the parent

Carnegie Mellon
fork Example
int main()  Call once, return twice
{
pid_t pid;
 Concurrent execution
int x = 1; ▪ Can’t predict execution
order of parent and child
pid = fork();
if (pid == 0) { /* Child */  Duplicate but separate
printf("child : x=%d\n", ++x);
exit(0);
address space
} ▪ x has a value of 1 when
fork returns in parent and
/* Parent */
printf("parent: x=%d\n", --x); child
exit(0); ▪ Subsequent changes to x
} fork.c are independent
Nb: in C/C++, ++x and --x are executed before printf()

What is the output
on the console ? linux> ./fork linux> ./fork
parent: x=0 or child : x=2
child : x=2 parent: x=0

Carnegie Mellon
Modeling fork with Process Graphs

 A process graph is a useful tool for capturing the ordering of
statements in a concurrent program:
▪ Each vertex (dot) is the execution of a statement
▪ a -> b means statement a happens before b
▪ Edges can be labeled with current value of variables
▪ printf vertices can be labeled with output

Carnegie Mellon
Process Graph Example

int main()
{
pid_t pid;
int x = 1;
child:x=2
pid = fork(); Child
printf exit
if (pid == 0) { /* Child */
printf("child : x=%d\n", ++x); x==1 parent:x=0
Parent
exit(0); main fork printf exit
}
/* Parent */
printf("parent: x=%d\n", --x);
exit(0);
}
fork.c

Carnegie Mellon
fork Example: Two consecutive forks

Bye
void fork2() printf

{ L1 Bye
printf("L0\n"); printf fork printf
fork(); Bye
printf("L1\n"); printf
fork();
L0 L1 Bye
printf("Bye\n");
} forks.c printf fork printf fork printf
How many processes Feasible output: Infeasible output:

are executed? Draw L0 L0
L1 Bye
the process graph and Bye L1
find one feasible and Bye Bye
one infeasible L1 L1
Bye Bye
execution trace Bye Bye
Carnegie Mellon
fork Example: Nested forks in parent

void fork4()
{
printf("L0\n"); Bye Bye
if (fork() != 0) { print printf
printf("L1\n"); L0 f
L1 L2 Bye
if (fork() != 0) { printf fork printf fork printf printf
printf("L2\n");
}
}
printf("Bye\n");
} forks.c Feasible output: Infeasible output:
L0 L0
L1 Bye
Draw the process graph and Bye L1
find one feasible and one Bye Bye
L2 Bye
infeasible output Bye L2

Carnegie Mellon
fork Example: Nested forks in children
void fork5()
{ L2 Bye
printf("L0\n"); printf printf
if (fork() == 0) { L1 Bye
printf("L1\n"); print fork printf
L0 f
Bye
if (fork() == 0) {
printf("L2\n"); printf fork printf
}
}
printf("Bye\n"); Feasible output: Infeasible output:
} forks.c L0 L0
Bye Bye
L1 L1
L2 Bye
Bye Bye
Bye L2

Carnegie Mellon
“Reaping” Child Processes

 Idea
▪ When process terminates, until “reaped” by its parent, it is not
removed from the system (so that parent can know child’s exit status)
and still consumes memory resources
▪ Called a “zombie” process: half alive and half dead
 Reaping
▪ Performed by parent on terminated child (using wait or waitpid)
▪ Parent is given exit status information
▪ Kernel then deletes zombie child process
 What if parent terminates and doesn’t reap?
▪ The orphaned child will be reaped by init process (pid == 1) after the
parent terminates
▪ So, reaping is required in long-running processes that create many
child processes such as shells and servers (otherwise memory will
eventually be exhausted)
Carnegie Mellon
void forks() {
Zombie if (fork() == 0) {
/* Child */
printf("Terminating Child, PID = %d\n", getpid());
Example exit(0);
} else {
printf("Running Parent, PID = %d\n", getpid());
while (1)
; /* Infinite loop */
}
linux> ./forks & } forks.c
[1] 6639
Running Parent, PID = 6639
Terminating Child, PID = 6640
linux> ps
PID TTY TIME CMD
6585 ttyp9 00:00:00 tcsh
6639 ttyp9 00:00:03 forks
 ps shows child process as
6640 ttyp9 00:00:00 forks <defunct> “defunct” (i.e., a zombie)
6641 ttyp9 00:00:00 ps
linux> kill 6639
[1] Terminated  When killing parent process, the
linux> ps child is reaped by init
PID TTY TIME CMD
6585 ttyp9 00:00:00 tcsh
6642 ttyp9 00:00:00 ps

Carnegie Mellon
void forks()
Child may not {
if (fork() == 0) {
terminate /* Child */
printf("Running Child, PID = %d\n",
before parent getpid());

while (1)
; /* Infinite loop */
} else {
printf("Terminating Parent, PID = %d\n",
getpid());
exit(0);
}
linux> ./forks & } forks.c
Terminating Parent, PID = 6675
Running Child, PID = 6676  Child process still active even
linux> ps though parent has terminated –
PID TTY TIME CMD child is “reparented” to init
6585 ttyp9 00:00:00 tcsh
6676 ttyp9 00:00:06 forks
6677 ttyp9 00:00:00 ps
 Must kill child explicitly, or else will
linux> kill 6676
linux> ps keep running indefinitely because of
PID TTY TIME CMD the while(1) loop
6585 ttyp9 00:00:00 tcsh
6678 ttyp9 00:00:00 ps
Carnegie Mellon
wait: Synchronizing with Children

 Parent reaps a child process by calling the wait function
(simpler version of waitpid with default argument)
 int wait(int *child_status)

▪ Suspends current process until one of its children terminates
▪ If child_status != NULL, then the integer it points to will be set
to a value that the exit status, i.e. that indicates reason the child
terminated and
▪ Return value is the pid of the child process that terminated, or
▪ When all the children have been reaped, the next call to wait returns
−1

Carnegie Mellon
wait: Synchronizing with Children

void fork9() {
int child_status;
HC exit
if (fork() == 0) { printf
printf("HC: hello from child\n");
exit(0);
CT
} else {
HP Bye
printf("HP: hello from parent\n");
wait(&child_status); fork printf wait printf
printf("CT: child has terminated\n");
}
printf("Bye\n");
} forks.c
Feasible output: Infeasible output:

Draw the process graph. What HP HP
is the output on the console if HC CT
the parent gets the CPU first CT Bye
Bye HC
after the fork() ?

Carnegie Mellon
execve: Loading and Running Programs

 int execve(char *filename, char *argv[], char *envp[])
 Loads and runs an executable file in the context of an already
existing process, overwriting the calling process:
▪ Executable file filename
Binary executable file or script file beginning with #!interpreter
▪
(e.g., #!/bin/bash)
▪ …with argument list argv
▪ By convention argv[0]==filename, argv[1] is first arg., etc
▪ …and environment variable list (information passed to the process) envp
▪ “name=value” strings (e.g., USER=Alice)
 Overwrites code, data, and stack of calling process

▪ But retains PID of calling process, open file descriptors
 Called once and never returns execve is one of the
variants of exec – such
▪ … except if there is an error such as functions are available
“program not found” under Unix and Windows
Carnegie Mellon
execve: more on environments variables

This slide is outside the scope of the course
 int execve(char *filename, char *argv[], char *envp[])

 Environment variables provides info on the context of execution of a
program, see
https://www.gnu.org/software/libc/manual/html_node/Standard-
Environment.html
 For how to access environment variables from within a program, see
https://www.gnu.org/software/libc/manual/html_node/Program-
Arguments.html
 We assume the use of envp in this lecture

Carnegie Mellon
execve Example
 Executes “/bin/ls –lt /usr/include” in current process:
Null-terminated array of pointers to character strings
myargv[3] = NULL
myargv[2] “/usr/include”
myargv[1] “-lt”
myargv myargv[0] “/bin/ls”
envp[n] = NULL
envp[n-1] “PWD=/usr/joe”
…
envp[0] “USER=joe”
envp
…
if (execve(myargv[0], myargv, envp) < 0) {
printf("%s: Command not found.\n", myargv[0]);
exit(1);
}
/* control flow will never reach this point if call to execve is successful */
}
Carnegie Mellon
execve summary
Recap: programs vs. processes
▪ a program is code + data typically stored in an object (=binary) file
▪ a process is a specific instance of a program in execution
▪ fork runs the same program in a new child process
▪ execve loads and runs a new program in the context of the current process
How to run a different program from the current process without terminating
the current process ? like command shells do
if (fork() == 0) { /* Child */
if (execve( myargv[0], myargv, envp) < 0) { /* replaces child */
printf("%s: Command not found.\n", myargv[0]);
exit(-1);
}
}
Outside the scope of the course - examples and further info at

https://medium.com/@birnbera/if-you-build-simple-shell-they-will-come-
855a28e2558b

Carnegie Mellon
Summary
 Creating processes
▪ Call fork
▪ One call, two returns
 Process completion
▪ Call exit
▪ One call, no return
 Reaping and waiting for processes
▪ Call wait (or variant)
 Loading and running programs
▪ Call execve (or variant)
▪ One call, (normally) no return

Carnegie Mellon
SCHEDULING PROCESSES:
DECIDING THE EXECUTION ORDER

Carnegie Mellon
The CPU scheduler

The scheduler selects - according to a scheduling policy - a
process to execute from the processes in ready state
CPU scheduling decisions (“scheduling points”) may take place
when a process:
1. When a process becomes blocked (switch from running to waiting state)
2. When a process gives back the CPU (switch from running to ready state)
3. When a process gets unblocked (switch from waiting to ready)
4. When a process terminates
5. Upon a timer interrupt (e.g. each 10ms)
Scheduling can be non-preemptive or (most often) preemptive
(=a running process can be interrupted and will be resumed at a
later time)

Carnegie Mellon
The dispatcher
 The dispatcher gives control of the CPU to the process
selected by scheduler; this involves:
1. switching context (e.g., saving/restoring registers)
2. jumping to the proper location in the code to restart that
process (can be considered part of the context switch as
instruction pointer register holds the next address to execute)
 Dispatch latency – time it takes for the dispatcher to
interrupt one process and start another

Carnegie Mellon
Different goals for different schedulers

1. Interactive scheduler: minimize perceived delay from
user’s perspective (<150ms) – ex: shells and GUI, general
purpose OS
2. Batch scheduler (execute batch of CPU-intensive
process): optimize throughput
3. Real-time scheduler: Meet process timing constraints
(deadline constraints most often, time at which execution
finishes)
Different schedulers can be used at the same time by an
OS (e.g. Linux supports all 3 types). There are priorities
between schedulers, and between processes scheduled
with the same scheduler (according to the “nice” level) –
see http://man7.org/linux/man-pages/man7/sched.7.html
(latter link outside scope of course)
Carnegie Mellon
Possible scheduling goals: an overview

 CPU utilization – keep the CPUs as busy as possible (all
systems)
 Minimize response time (=time it takes to for a process to
complete) – responds to requests quickly (for interactive
systems)
 Meeting deadlines (for real-time systems)
 Throughput – # of processes that complete their
execution per time unit (for batch system)
 Fairness between processes / users
 Etc … How can we define fairness? Give an
example of a fair scheduling policy?
A scheduling policy is said to be optimal wrt to a certain
criterion if no other policy can outperform it wrt to the criterion
(“no possible regret in using the optimal policy”)
Carnegie Mellon
Standard scheduling policies for batch

processing
 First-Come First-Served (=FIFO) If all processes are ready at
 Shortest Job First time 0, what is the average
response time (aka avg
 Shortest Remaining Time Next
turnaround time) with both
Shortest Job First is optimal wrt
policies? How do you explain
avg waiting time – the problem is the result ?
to know the length of next CPU
request!
An example of shortest job first scheduling.

(a) Running four jobs in the original order.
(b) Running them in shortest job first order.
Carnegie Mellon
Scheduling in interactive Systems:

examples of policies
 Round-Robin Scheduling : each process is given a fixed
time quantum then it yields the CPU
 Priority Scheduling: processes are executed in the
order of their priorities
 Age-based scheduler: the older the process, the less
CPU it receives (to favor newer/interactive processes)
 …

Carnegie Mellon
Round-Robin Scheduling : typical

implementation
B is moved to the end of

the ready queue once it
has used its quantum
Round-robin scheduling. (a) The list of

runnable processes as stored in the kernel. (b) The list of runnable
processes after B has used its quantum.

Carnegie Mellon
Priority Scheduling: typical implementation

The scheduler sweeps the queues from
highest to lowest priority queue when it
needs to make a scheduling decision
Here four priority classes are possible

(many more in OSes)
Carnegie Mellon
THREADS

Carnegie Mellon
What is a thread ?
 A “lightweight” process within a process which does not
have its own address space but serves the same purpose of
running activities in parallel
 Enables to define multiple flows of control within a process
(a) Three processes each with one thread. (b) One process
with three threads.
Carnegie Mellon
Three threads within a process instead

of three processes with one thread
Each thread has its own stack but resides in the same address
space. Processes start with a single thread (the main thread) which
is going to create new threads by calling a function in a library.
Each thread is identified by a unique Id.
Carnegie Mellon
A Process With Multiple Threads

 Multiple threads can be associated with a process
▪ Each thread has its own logical control flow (and thus its own Program Counter)
▪ All threads share the same code and data
▪ Each thread has its own stack - but not protected from other threads
▪ Each thread has its own thread id (TID)
▪ The main thread is first thread to run in the process
Thread 1 (“main” thread) Thread 2 (“peer” thread) Shared code and data
…
stack 1 stack 2
run-time heap
read/write data
Thread 1 context: Thread 2 context:
Data registers Data registers read-only code/data
SP1 SP2 0
PC1 PC2
… …
SP1: stack pointer of thread #1
PC1: program counter of thread #1
Carnegie Mellon
Logical View of Threads

 Threads associated with process form a pool of peers
▪ Unlike processes which form a tree hierarchy
▪ Similar functions as for processes to create, kill, reap threads
Process hierarchy
Threads associated with process foo
P0
T2
T4
T1 P1
shared code
and data
sh sh sh
T5 T3 foo
bar

Carnegie Mellon
Example of thread Usage (1) - thread-based

client server program
Connection requests
Listening
server
main thread
Client 1’s Client 2’s
Client 1 data server server Client 2 data
peer peer
thread thread
▪ Each client handled by individual thread

▪ Threads share all process state except TID
▪ Each thread has a separate stack for local variables
▪ Ex: a multi-threaded Web server with one thread per TCP
connection
Carnegie Mellon
Example of thread Usage (2)
A word processor with three threads: e.g., the editor, the

spell-checker and the auto-save feature
rights
Bryant andreserved.
O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 54
Carnegie Mellon
Using threads instead of processes : pros and cons

 Advantages
▪ Much faster to create a thread than a process
▪ Much faster to switch between threads than to switch between
processes
▪ Inter-thread communication (e.g., sharing data through variables) is
straightforward and fast, unlike inter-process communication
 Disadvantages
▪ No memory protection between threads, one thread can modify the
other threads’ data and kill the entire process
▪ Interaction between threads can be tricky (“What happens if one
thread closes a file while another one is still reading from it?”)
▪ More difficult to know exactly when threads will execute because of
hierarchical scheduling (a process is selected for execution then a
thread within that process)
Carnegie Mellon
Keeping track of the state of processes and

threads
Not exhaustive! Process table in kernel comprises more entries
The first column lists some items shared by all threads in a

process. The second columns lists some items private to
each thread.
Nb: a non-multithreaded process is mono-thread.
rights
Bryant andreserved.
O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 56
Carnegie Mellon
END OF LECTURE 6

Lecture 6

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lecture 6

Uploaded by

Copyright:

Available Formats

Carnegie Mellon

Processes, threads and their scheduling

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 1

Processes, threads and their scheduling

PROCESS: A KEY ABSTRACTION

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 3

Preamble - Flow of Control

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 4

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 5

Concurrent processes, multitasking &

These 3 processes are said to run concurrently

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 6

Computers run many processes simultaneously

 Running program “top” on Unix-like OS (here Mac OS)

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 8

Switching from one process to another: saving &

 When the OS decides to transfer control to another

What is the impact of

 Control flow passes from one process to another via a

context switch Process A Process B

kernel code context switch

kernel code context switch

Cache pollution: when a process resumes after a context

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 11

Process Management Activities

The OS is responsible for the following tasks:

 Creating and terminating both user and system processes

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 12

Process States (1)

Process States (2)

A process can be in running, blocked, or ready state (default state

Next: process termination & process creation

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 14

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 16

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 17

Nb: in C/C++, ++x and --x are executed before printf()

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 18

Modeling fork with Process Graphs

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 19

Process Graph Example

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 20

fork Example: Two consecutive forks

void fork2() printf

How many processes Feasible output: Infeasible output:

fork Example: Nested forks in parent

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 22

fork Example: Nested forks in children

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 23

“Reaping” Child Processes

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 25

before parent getpid());

wait: Synchronizing with Children

 int wait(int *child_status)

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 27

wait: Synchronizing with Children

Feasible output: Infeasible output:

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 28

execve: Loading and Running Programs

 Overwrites code, data, and stack of calling process

execve: more on environments variables

 int execve(char *filename, char *argv[], char *envp[])

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 30

Outside the scope of the course - examples and further info at

 int execve(char filename, char argv[], char *envp[])