[551] in Pthreads mailing list archive
Re: non-standard functions
daemon@ATHENA.MIT.EDU (Christopher Provenzano)
Fri Jan 24 08:21:55 1997
Reply-To: proven@cygnus.com
To: Cheryl Huntington <clh@swdc.stratus.com>
Cc: pthreads@MIT.EDU
In-Reply-To: Your message of "Wed, 22 Jan 1997 16:26:19 PST."
<32E6B02B.15FB7483@swdc.stratus.com>
Date: Fri, 24 Jan 1997 07:55:42 -0500
From: Christopher Provenzano <proven@proven.org>
> I have found the following functions defined in this implementation
> which are not defined in the finalized POSIX standard. Is this because
> the implementation is based on an earlier draft? A lot of them are
> clearly used within the library, but are they intended to be callable by
> applications? If not, isn't is standard to prefix internal functions
> names with "_"? I'm not intending to be critical, just trying to
> understand their purpose.
Yeah, I should have used __ to prefix all internal routines.
>
> pthread_cond_is_debug()
> pthread_mutex_is_debug()
These are internal and are declared static.
> pthread_dump_state()
> pthread_dump_info()
These are useful debugging routines that aren't standard.
> pthread_dump_info_to_file()
More debugging stuff. It is only called from pthread_dump_info() and is
declared static.
>
> pthread_mutexattr_gettype()
An extension. I support recursive mutexes along with debugging mutexes.
> pthread_attr_setcleanup()
An extension. This sets a cleanup handler for the initial arg of the threads
initial routine. The handler is invoked when the thread exits.
Useful when you want to pass allocated data to a new thread.
> pthread_attr_getfloatstate()
> pthread_attr_setfloatstate()
More extensions. If you know a thread isn't going to use an floating point
data then you can turn off saving of the floating point state during a context
swicth. Currently it only effects performance on the i386. Look at the
benchmark p_bench_yield for an indication of the performance inprovement.
> pthread_init()
Early versions required that pthread_init() be called first thing in main.
This is no longer true but I leave it in for backwards compatiblity.
> pthread_cleanupspecific()
Internal routine.
> pthread_key_allocate_data()
Internal routine. Declared static.
>
> pthread_prio_queue_init()
> pthread_prio_queue_deq()
> pthread_prio_queue_remove()
Internal routines only.
> pthread_yield()
Earlier drafts of the standard used this instead of sched_yield().
I leave it in for backwards compatibility.
> pthread_queue_init()
> pthread_queue_enq()
> pthread_queue_get()
> pthread_queue_deq()
> pthread_queue_remove()
> pthread_llist_remove()
> pthread_sched_other_resume()
> pthread_resched_resume()
> pthread_sched_resume()
> pthread_sched_prevent()
More internal routines. If you know what you're doing you can use
pthread_sched_prevent() and pthread_sched_resume() to stop and restart
thread scheduling.
> pthread_setup_siginfo()
Internal setup of a SIGINFO handler.
> pthread_sig_register()
> pthread_sig_default()
> pthread_sig_process()
Internal routines.
> pthread_signal()
Current user replacement for signal() routine because internally I use
signal() instead of machdep_sys_signal(). I haven't implemented a
machded_sys_signal() yet because it will require hand coded machine code.
> pthread_sigprocmask()
User replacement for sigprocmask(). The standard says using sigprocmask()
results in undefined behavior. Currently I have sigprocmask doing the
same thing as pthread_sigprocmask() which to me is the only sane thing
it should do.
>
> pthread_atexit_inited()
> pthread_atexit_add()
> pthread_atexit_remove()
> pthread_attr_destroy_nrv()
More extensions. This is yet another way of dealing with cleanup.
These routines are in a separtate library.
> pthread_tad_count()
> pthread_tad_done()
> pthread_tad_start()
> pthread_tad_create()
> pthread_tad_wait()
> pthread_tad_init()
> pthread_tad_destroy()
Yet more extensions. A set of routines for dealing with a group of threads
all doing the same type of task. The idea is that threads doing the same
type of task will have the same attributes and that you may want to keep
track of them as a group. These routines are in a separtate library.
CAP
