Index of /tcl/ftparchive/sorted/net/svipc-2.2.0

      Name                   Last modified     Size  Description

[DIR] Parent Directory 28-Oct-99 15:46 - [   ] README 10-May-96 12:51 6k [CMP] svipc-2.2.0.tar.gz 24-Jun-96 19:41 41k


	       Tcl Interface to System V IPC Facilities

			     Version 2.2

This package provides Tcl commands to access the System V IPC
facilities: semaphores, shared memory and message queues.  This
package provides only Tcl commands---I did not feel it necessary to
provide a C interface, since the system calls already provide that!
Also, the Tcl commands don't keep any usefule state that C functions
need to access.

Highlights for version 2.2.0:

o   Updated to support dynamic loading in Tcl7.5.  This release *only*
    supports dynamic loading and does not support static linking.
    There are no changes to the underlying commands, so if you need to
    statically link this library, get version 2.1.1 and use it.

o   This release makes no effort to support the Mac and Windows
    environment.  I really don't see any way to do it, or any real
    need to do it either.  I suppose some might argue for support
    under the NT Posix environment, but that also seems pointless
    since that environment has no usable connection to the NT Windoze
    environment, which more people seem interested in...

Highlights for version 2.1.1:

o   Makefile.in updated to tcl7.3, tk3.6, and tclX7.3a.

o   Fixed incorrect msgctl calls in svipcMsg.c.

o   I have a report that the prototype for shmat in svipcShm.c conflicts
    with the standard prototype used by shm.h on HP-UX 9.0.  I don't
    know exactly *what* the conflict involves, nor how I can detect it
    to fix it.  I need a method of detecting the incompatible prototype
    so that I can update configure.in to support conditionally
    *excluding* the offending code (preferrably a grep command that
    finds the offending prototype in shm.h or wherever it appears.)

o   Added many new and exciting variables to the Makefile.  These includes
    srcdir for use in compiling from a directory other than the actual
    source directory.  Also use LDLIBS in conjunction with defining
    TCLLIB, etc. to specify use of installed libraries (e.g., ``make -k
    LDLIBS=/sea/ntu/tools/lib TCLLIB=-ltcl TKLIB=-ltk TCLXLIB=-ltclx
    TKXLIB=-ltkx'' to compile using libraries installed in
    /sea/ntu/tools/lib.)

o   make install-lib now installs the modified xxxAppInit.c files in
    $(libdir)/svipc directory, so you can make distclean after install.

Highlights for version 2.1.0:

o   Fixed incorrect manual pages inadvertently shipped with 2.0.

o   Updates INSTALL and README files not updated for 2.0.

o   Allow use on SVR4-compatible systems which do not declare ``union
    semun'' in sys/sem.h.

o   Compatible with Tcl7.2/Tk3.5/TclX7.2a.

Highlights for version 2.0:

o   An extension of the Tcl_LinkVar procedure provided in Tcl 7.0 to
    support more data types.

o   linkvar and unlinkvar commands to support using Tcl_LinkVar from
    Tcl programs.

o   An example of a sed script to add application-specific init
    procedures to tlcAppInit.c and tkAppInit.c.

Note on backward compatibility:  This version *only* works on Tcl 7.0
and Tk 3.3.  Get SVipc-1.0 if you want to use Tcl 6.7 or earlier.

Details:

For version 2, I have added autoconf support and support for Tcl7.0
and Tk3.3 (I have made NO provisions for backward compatibility---the
new features depend on corresponding Tcl7.0 features.)  I have also
taken the Tcl_LinkVar procedure and enhanced it to support signed and
unsigned chars's and short's, and static character strings.  This
allows you to access locations in shared memory without using the
``get'' and ``set'' interface, resulting in increased performance over
using variable tracing in Tcl procedures.

I have also renamed all functions using the ``Svipc_'' prefix instead
of ``Tcl_'', and renamed all of the source files to reflect this
change.  I have also done some minor re-formatting and code cleanup.

I provide a very straight-forward interface.  For each facility, I
provide a ``get'', ``set'', ``stat'' and ``rmid'' command.  The
``get'' command provides the same interface as the ``get'' system
calls (msgget, semget, shmget): given an IPC key, return the
internal IPC handle for the requested item, optionally creating it if
it doesn't yet exist.  The ``set'', ``stat'' and ``rmid'' provide an
interface to functions in the ``ctl'' system calls (msgctl, semctl,
shmctl.)

To actually generate the IPC keys, I provide an interface to ``ftok''.

Then, for each facility, I also provide access to facility-specific
commands: msgsnd, msgrcv, semop, semval, shmat, shmdt.  For message
queues and semaphores, the extra commands do the obvious thing: send
and receive messages and get or set semaphore values.  Shmat and shmdt
attach and detach the shared memory segment.

Shared meory access poses a different issue.  You can access memory
locations directly using a set of ``get'' and ``set'' routines, or you
can set variable traces between Tcl variables and memory locations
using ``link'' and ``unlink''.  Getchar, getlong, and getshort return
the contents of the addressed memory as signed integers.  Setchar,
setlong and setshort take a list of integers and set the addressed
memory to those values.  Getstr and getstrn return the memory contents
interpreted as strings (using strcpy and strncpy.)  Setstr and setstrn
copy the strings into memory.

The link and unlink commands implement an extension of the
Tcl_LinkVar() procedure called Svipc_LinkVar().  This proceudre allows a
greater number of types than the standard Tcl version and also allows
access to arrays of locations, returned as a list of values.

Since Tcl functions can't really determine arbitrary program
addresses, the functions only work with the address returned by shmat.
I don't do any address validation in the get and set routines except
for alignment checks for short and long.

Anyway, I have found it quite easy to use these facilities in
conjunction with variable traces to make Tcl variables ``mirror''
shared memory locations and semaphores.  Sorry, I can't post *that*
code, however the implementation using the ``link'' and ``unlink''
commands seems obvious to me...

If you have any questions, don't hesitate to get in touch with me.

Joe Kelsey				joe@zircon.seattle.wa.us