Miscellaneous Pointers and Notes for KAPL section.

Outline and ELF symbol table printouts about relocation and linking
http://www.cs.albany.edu/~sdc/kapl/pub/LectureMaterial/log.html#26

Please read Beck chapter 3 on your own, and study enough of chapter 1, 2 and Appendix A to understand the examples.
 

 Loading of Solaris executable files into virtual memory:: http://www.cs.albany.edu/~sdc/kapl/pub/LectureMaterial/Lecture25/ 

Slide showing how a segment in the ELF executable file is copied or mapped into the virtual memory of the process being oaded:: http://www.cs.albany.edu/~sdc/kapl/pub/LectureMaterial/Lecture25/elf_segment_headers.ps

 Pointers to other figures shown in class and other resources for details: http://www.cs.albany.edu/~sdc/kapl/pub/LectureMaterial/Lecture25/ElfResources/

 The gory details from the Solaris Answerbook of the ELF format on Solaris, for both object and executable files http://eve.albany.edu:8888/ab2/coll.45.10/LLM/@Ab2PageView/14826? 
 

 http://www.cs.albany.edu/~sdc/csi402/Images/linking.jpg

This slide shows how two object files in ELF format are linked to form the ELF executable file.  Under that, it shows the contents of the virtual memory as they are set up by the operating system's loader when it runs the exec system call on the executable file.  Note that the .text and the .data segment ranges are specified in the segment header table of the ELF executable file.  The stack segment address range is not specifed in the ELF executable.  The operating system loader sets up and initializes the stack with a virtual address range the loader determines by itself.
 

This slide shows a single threaded process IN EXECUTION.  The process state consists of
• The ranges of virtual address space that are "legal."   Only addresses in the legal ranges can be dereferenced without causing a bus or segmentation error.
• The contiguous ranges of legal address space with common access properties (read, write or execute) are called SEGMENTS.
• The stack is in one of the segments.
• The heap is in another one of the segments.
• The contents of each virtual memory segment.
• The contents of programmer visible CPU registers, including the PC.
• State maintained by the operating system:  open files and other objects described by file descriptors, message queues, semaphores, shared memory objects, scheduling information, userid, etc, etc.(NOT SHOWN, NOT stored in the process's own segments)

The next slide shows how the picture of a process changes when the process has two (or more) THREADS.  All the threads share the same virtural memory space, so data communication using shared memory between threads is trivial.
• A thread is sometimes called a "lightweight process".  The difference between a (heavyweight) process and a lightweight process or thread is that a process has its own address space, virtual memory and operating system resources in addition to CPU register set, but a thread or lightweight process resides within a (heavyweight) process so all threads in one process share the same address space, virtual memory and operating system resources.  This clearly makes heavyweight process creation and context switching take longer time than thread creation and switching in an already created process.
• Each thread has its own stack.  The thread library and the programmers must make sure the stacks do not run into each other!
• Each thread has its own "virtual" CPU with its own set of registers and program counter.

Some thread libraries "schedule" the single thread supplied by the operating system among the threads run by the library.  Others, such as Linux and optionally under Solaris, have the operating system schedule the threads.  For the latter, the operating system must support multithreaded processes.  Current versions of Solaris, Linux and Windows9x do support multithreaded processes.

This slide shows how free-store ("malloc'ed or dynamic") memory can be used for communication of data between threads.  The stack or registers of one thread can contain pointers to free-store memory spaces that were requested by other threads.
• Such pointers can be passed from one thread to another through function parameters: The thread creation library copied the parameter from a register or stack variable of one thread to a registers or stack variable of the new thread.
• Threads can also communicate through global static variables.  But the programmer must be careful!!
• Buffer or stack overflows, illegal pointers, etc can cause threads to mess up each other's variables.  This creates bugs that are very hard to find and fix.
Multithreaded applications will probably become increasingly common..See various current books on thread programming.

 http://www.cs.albany.edu/~sdc/csi402/Images/nothreads.jpg
This slide shows the roles and operations of the server and the client when BSD SOCKETS are used for interprocess communication.

The server is the "passive" partner in the communication.  Basic server steps:
1. Construct the socket and keep the file descriptor to refer to it.
• Use the socket() system call.
• Specify the domain, type, and protocol
• See textbook material on sockets.
2. Bind an address to the socket.
• Use the bind() system call.
• Specifies the name that prospective clients can specify in order to get connected with THIS server.
Rendezvous:  The name is needed so the client and server can find each other.
Internet domain socket names include the PORT number, to distinguish different servers on the same internet network host.
Local (Unix) domain socket names are PATHNAMES, just like the names of named pipes.
• Programmer must construct an instance of the particular address structure type for the domain specified for this socket.
• The pointer to the address structure is cast to (struct sockaddr *) so it can be passed as the 2nd argument to bind() without raising a compile time C type clash error.
• The programmer must specify the length of the address structure through the 3rd argument.
3. Put the socket into the listening state
• Use the listen() system call.
• Specify the backlog.  That is how many pending connect requests will be queued by the server.
4. Wait for a connection.
• Use the accept() system call.
• accept() will block until a connection is established
• accept() stores the client's address into a struct sockaddr that the programmer must provide.  The programmer must make sure enough space is available at the pointer passed as the 2nd argument.  The 3rd argument is a "value-result" parameter:  The programmer passes a pointer to an int variable that specifies the amount of space available at the address given by the 2nd argument.  The accept() system call replaces the amount of space value with the numbe of bytes the accept function actually writes into the space pointed to by the 2nd argument.
• Other functions (recvmsg() or getsoctopt()) can be used to find out about a requested connection without confirming it.
5. Read and Write to communicate data.
• Use the read() and write() system calls on the NEW socket file descriptor returned by accept().
• These functions may block.
6. Close the connection (not shown)
• Use the close() system call on the socket file descriptor returned by accept().
7. Maybe shutdown the server by closing the listening socket file descriptor (not shown)

The client is the "active" partner in the communication.  It initiatiates the connection.  Basic client steps:

1. Construct the socket similar to server.
2. Try to connect
• Use the connect() system call.
• Programmer fills in a struct sockaddr with the address
• The address corresponds to the RENDEZVOUS name bound to the server.
• /etc/services lists standard port numbers used for "well-known" Internet services.
• The standard file name for local connections to a X server is seen from:
myrtlewood:/$ ls -l /tmp/.X11-unix
srwxrwxrwx   1 root     sdc             0 Apr 18 22:06 X0
The pathname is /tmp/.X11-unix/X0
The "s" on the directory listing indicate the file is a socket.
• connect() blocks until the connection is completed (or an error is detected).
3. Read and Write to communicate data using the read() and write() system calls on the socket's file descriptor.
4. Close the connection by running close() on the socket's file descriptor (not shown)

 http://www.cs.albany.edu/~sdc/csi402/Images/threadedserver.jpg

Here is a multithreaded server.  A new thread (green, blue) is created to serve each client connection.  The original thread (red) continues to listen for additional client connections.  It is blocked most of the time, so it consumes little CPU resources.

Simple Posix thread demonstration program http://www.cs.albany.edu/~sdc/kapl/pub/LectureMaterial/log.html#35

Notes on using Posix threads. http://www.cs.albany.edu/~sdc/kapl/pub/LectureMaterial/log.html#36 

 See lecture outline:: http://www.cs.albany.edu/~sdc/kapl/pub/LectureMaterial/log.html#34