"Ralf S. Engelschall" wrote:
> Please post all your patches here. I'll look at them and try
> to pick them up for inclusion into Pth 1.4.1.
This is not related to the current thread, but maybe this is a good
time to mention my pth "wish list".
I'd be interested also in other people's comments, I'm sure many
of these ideas are arguable..
PTH WISH LIST
-------------
- During initialization, Pth should call fcntl(fd, F_SETFD, 1) on
all private file descriptors (i.e., the private pipe). This is so
that if your process does a fork()/exec() the fd's are not inherited.
Yes, the correct thing to do is pth_fork() but this wouldn't hurt.
- pth_init() should allow the user to supply custom malloc(), realloc(),
and free() routines that Pth will use for all memory requests.
- Add PTH_EVENT_WAITPID?
- The pth_msgport stuff is not object oriented (you must include the
structure in your own structure) and from the man page it is not clear
how to actually create one.
- Precisely document all return value possibilities: e.g., some functions
return TRUE/FALSE while others may return -1 and errno. Not always clear.
- It would be nice if pth_cond_await() didn't require a mutex (i.e., that
field could be NULL). Because pth threads are non-preemptable, it is
usually the case that the mutex is completely unnecessary (or so I've
found).
- PTH_EVENT_FUNC is useful for defining user-defined events, but it operates
on a polling basis. How about a new event type PTH_EVENT_USER that a thread
may wait for, and which another thread triggers by calling pth_user_event()
or somesuch, hence a non-polled user event.
- Have pth() call pth_cancel_point() just before entering a new thread's
main() routine. This avoids the race condition between starting and then
immediately canceling a new thread -- currently, sometimes the thread is
canceled immediately (i.e., it never starts) and other times it starts
and runs until the first cancelation point before being canceled. I think
it depends on whether there has been a context switch (?)
- Add Java-like support for a "thread manager". E.g., allow a setup where
SIGSEGV, SIGBUS, etc. can be gracefully handled, so that if a thread
crashes, then another thread is awoken and allowed to do something about
it (clean up, restart the thread, etc). Can this already be done somehow?
- Allow the user to supply a callback function that is called every time
Pth is about to do a context switch. This would make it easy to add code
that checks for non-preemption, using assert() or somesuch. Typically
many functions are written with the assumption that they won't be
preempted, but it's non-trivial to verify that if these functions call
a lot of other functions.
- pth_cond_notify() should have a new boolean argument that means
"but don't context switch just yet!!"
Cheers,
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
______________________________________________________________________
GNU Portable Threads (Pth) http://www.gnu.org/software/pth/
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager (Majordomo) [EMAIL PROTECTED]
