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

Re: Programming with LinuxThreads2

Hash: SHA1

Kevin Mihelich wrote:

> First, how is the API changed for programming with the new threads? Are
> the commands the same, just program as I did with the old linuxthreads?
> Anything special required in my programs?

The announcement text contained a number of details:

- - The signal handling changes from per-thread signal handling to the
  POSIX process signal handling.  This change will require changes in
  programs which exploit the non-conformance of the old implementation.

  One consequence of this is that SIGSTOP works on the process.  Job control
  in the shell and stopping the whole process in a debugger work now.

- - getpid() now returns the same value in all threads

- - the exec functions are implemented correctly: the exec'ed process gets
  the PID of the process.  The parent of the multi-threaded application
  is only notified when the exec'ed process terminates.

- - thread handlers registered with pthread_atfork are not anymore run
  if vfork is used.  This isn't required by the standard (SUS, since
  POSIX does not defined vfork at all) and all which is allowed in the
  child is calling exit() or an exec function.  A user of vfork better
  knows what s/he does.

- - libpthread should now be much more resistant to linking problems: even
  if the application doesn't list libpthread as a direct dependency
  functions which are extended by libpthread should work correctly.

- - no manager thread

- - inter-process mutex, read-write lock, conditional variable, and barrier
  implementations are available

- - the pthread_kill_other_threads_np function is not available.  It was
  needed to work around the broken signal handling.  If somebody shows
  some existing code which makes legitimate use of this function we
  might add it back.

- - requires a kernel with the threading capabilities of Linux 2.5.36.

More will come when I have the time to write things down.  There are
definitely changes necessary in some programs but only those which
relied on non-POSIX behavior in the old implementation.  This has always
been discouraged.

> Second, are there any stats on the memory usage of the new linuxthreads?
> The old one had the 2mb allocation per thread, is the new one lighter on
> that load?

The POSIX interface allows the programmer to determine the stack size.
Every since we introduced the "floating stacks" in LinuxThreads this has
been the responsibility of the programmer.  Some default size in case no
stack size is specified has to be used(specified either by the
programmer or by the user using ulimit before starting the application).
 I have no reason to go away from the 2MB default since I had about the
same amount of people whining about a stack which is too small as I had
people whining about the opposite.

- -- 
- ---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


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