On Wed, Oct 23, 2002, Matthew Mondor wrote:
> [...]
> First, I noticed that pth_msgport_create(), although inspired from the
> AmigaOS API, does not support NULL for port identifyer, which would be
> very useful for thread-specific private message ports (mmftpd uses those
> and unfortunately currently has to generate unique strings to create
> ports). AmigaOS had this functionality...
Good idea. The name for pth_msgport_create() is actually only required
of one wants to search the message port via pth_msgport_find(). So I've
changed this now for GNU Pth 1.5.0 to allow a NULL name, too. Thanks for
the hint.
> Another suggestion would be exporting the low-level pth_mctx_*() interface
> so that applications that only need portable context
> switching/manipulation features could possibly use it. Those could then be
> documented as well in the man page... For instance a real-time kernel
> scheduler implementation I have been working on a while back, could easily
> be tested on unix in a portable manner. It's unfortunate that the SVR4 API
> is not part of all unices, and that sigaltstack fiddling is architecture +
> platform dependant. But Pth has all this for us already, it's just not
> exported publically. Possibly that an SVR4-inspired public API could be
> made part of future Pth versions.
Yes, the same idea is also on my TODO list. Unfortunately it is perhaps
not as easy as it looks, because some of the pth_mctx_*() stuff is just
macro based and hence exporting it means moving it physically to pth.h
-- perhaps with other side-effects. I'll look into this, perhaps we
could wrap the pth_mctx_*() functionality with extra C function for
easier exporting.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
GNU Portable Threads (Pth) http://www.gnu.org/software/pth/
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager (Majordomo) [EMAIL PROTECTED]
