The TPF Process Model

past, present and future


Traditional TPF Process Model: TPF 3.1 and Prior
o real address space
o entry control block = dispatchable unit of work
- CP interfaces
o loosely managed memory
o fixed size program blocks

TPF 4.1 Model
o virtual addressing
- new concept: ecb virtual memory
- evm = ecb virtual machine

o memory management impacts
- traditional fixed size core blocks
- new application heap
- support for high level languages (C/C++)

o CLM/DLL


What is driving process model change?
o requirements driven y portable code
- e-business = TCP/IP and related daemons
- web sever (apache)
- RPC
- Other requirements to come, primarily POSIX

Change made already
o POSIX file system
- user/group affinities
o New POSIX features
- synchronous 'unreliable" signals
- process spawning: tpf_fork()
o TCP/IP protocol

What Else"
o signals
- reliable signals
o multithreading
- pthreads
o multiprocessing
- true support for fork
- pipes
0 memory management
- shared memory

Traditional applications impacted?
o NO
o complete traditional process model continues to be supproted
o no effect on those appliucations who choose not to use the newer process
  model features

What do the changes mean?
o more power, freedom of design
o independence from ECB references
o ability to code entirely in c/c++ with a minimum of TPF-unique code
o continued backward compatibilit with traditional (pre 4.1) modeled applications.


How can we use this model?
o enhanced file transport and data sharing facilities
- TFTP
- FTP, NFS
o remote procedure call RPC
o further support for object-oriented programming connectivity
- Java
- Corba: object request brokering