[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GNU Portable Threads (Pth) 2.0.2 released

From: Ralf S. Engelschall
Subject: GNU Portable Threads (Pth) 2.0.2 released
Date: Sun, 12 Sep 2004 15:03:39 +0200
User-agent: Mutt/

GNU Pth 2.0.2 is now available:

Pth is a very portable POSIX/ANSI-C based library for Unix platforms
which provides non-preemptive priority-based scheduling for multiple
threads of execution (aka `multithreading') inside event-driven
applications. All threads run in the same address space of the server
application, but each thread has its own individual program-counter,
run-time stack, signal mask and errno variable.

The thread scheduling itself is done in a cooperative way, i.e., the
threads are managed by a priority- and event-based non-preemptive
scheduler. The intention is, that this way one can achieve better
portability and run-time performance than with preemptive scheduling.
The event facility allows threads to wait until various types of
events occur, including pending I/O on filedescriptors, asynchronous
signals, elapsed timers, pending I/O on message ports, thread and
process termination, and even customized callback functions.

Additionally Pth provides an optional emulation API for POSIX.1c
threads (`Pthreads') which can be used for backward compatibility to
existing multithreaded applications.

Finally, Pth guarranties its fixed set of API functionality on
all platforms, i.e., functions like pth_poll(3), pth_readv(3) or
pth_writev(3) are always available, even if the particular underlaying
platform does not actually support their functionality (through the
system calls poll(2), readv(2), writev(2), etc).

Although Pth is very feature-rich, it is a rather small threading
library. It consists only of approximately 7,000 line (or 300 KB) of
ANSI C code which are auto-configured with approximately 400 lines (or
60 KB) of Autoconf/m4 macros and which are documented by approximately
3,000 lines (or 150 KB) of documentation. Additionally the sources
are documented with approximately 3,600 additional lines of comments.
As a result, the whole source tree is just about 1.5 MB in size and
fits into a small tarball less than 350 KB in size. This allows Pth to
fit very well even into the source tree of other applications without
bloating it up very much.

Pth was successfully tested on FreeBSD, NetBSD, OpenBSD, BSDI,
GNU/Linux, Solaris, HPUX, Tru64 (OSF/1), AIX, IRIX, UnixWare, SCO
OpenServer, SINIX, ReliantUNIX, ISC, AmigaOS, Rhapsody (MacOS X), FTX,
AUX and Win32/Cygwin. And it should should automatically adjust itself
to remaining Unix platforms, too.

Changes between 2.0.1 and 2.0.2 (13-Jul-2003 to 12-Sep-2004):

 *) Added hard syscall wrappers for send(2) and recv(2).
    [NetBSD pkgsrc patches]

 *) Internally handle errors returned from pth_event() in order
    to pass them upstream to the caller in pth_high.c functions.
    [Ralf S. Engelschall, NetBSD pkgsrc patches]

 *) Fix syscall wrapper for sendto(2).
    [NetBSD pkgsrc patches]

 *) Use "(char *)NULL" instead of plain "NULL" in last argument to
    execl(2) to avoid GCC 3.5's "warning: missing sentinel in function call".
    [Ralf S. Engelschall]

 *) Workaround Autoconf/m4 problems in pth.m4 by using "m4_define"
    instead of just "define" and no using m4_undefine at all.
    [Dr. Andreas Mueller <address@hidden>]

 *) Avoid side-effects by defining _XOPEN_SOURCE only temporarily
    for inclusion of <poll.h> instead of permanently.
    [Graham Nash <address@hidden>]

 *) Workaround GCC 2.x and 3.5 (3.4 worked fine) macro parsing
    behaviour by using a pre-declared function pointer type "typedef
    int (*pth_event_func_t)(void *);" instead of using an inlined
    "int (*)(void *)".
    [Ralf S. Engelschall, Robert Anderson <address@hidden>]

 *) Fixed prototype for pthread_attr_setschedparam(3) from
    to use a "const struct sched_param *" argument.
    [Rafael Ávila de Espíndola <address@hidden>]

 *) Upgraded build environment to GNU libtool 1.5.8
    and GNU shtool 2.0.1.
    [Ralf S. Engelschall]

                                       Ralf S. Engelschall

reply via email to

[Prev in Thread] Current Thread [Next in Thread]