Date: Thu, 9 Dec 1999 06:42:56 -0600 From: "Richard Seaman, Jr." <dick@tar.com> To: Jason Evans <jasone@canonware.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Possible libc changes to support LinuxThreads Message-ID: <19991209064256.B34152@tar.com> In-Reply-To: <19991209003517.E73529@sturm.canonware.com> References: <19991209003517.E73529@sturm.canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 09, 1999 at 12:35:17AM -0800, Jason Evans wrote: > I've got a port of the most recent LinuxThreads (glibc-linuxthreads-2.1.2) > running, Great! > but ran into a couple of minor problems integrating with our libc. > LinuxThreads redefines a number of functions in order to make them either > support thread cancellation or work correctly. > > The following functions need an alternative name, just as, for example, > write() is actually _write(): > > lseek() > pause() > system() > tcdrain() > wait() > waitpid() > recv() > send() > > This would allow implementing cancellation points for these functions. All > in all, I won't lose much sleep over this, but if it's easy to do and > doesn't violate some rule of symbol naming, it would be nice. It's my impression that glibc uses a three (four?) tiered naming convention. The "pure" syscall (in our case, eg. _write()). Then there is the version used internally in glibc (eg. _libc_write(). And finally, the version exported from glibc (eg. write()). The merit to the three tiered system is that you might need to rewrite the version used internally to libc for threads, but still have this be different from the version exported from the library (eg. to implement cancallation points without propagating them throughout libc). In this case, you'd want, for example, an _lseek(), _libc_lseek(), and _seek(). The problem with cancellation points, libc and linuxthreads has been that you need to wade through libc and replace instances of, for example, write() with either _write() or _libc_write() in order to avoid propagating cancellation points where they don't belong. > The other issue has to do with longjmp() and siglongjmp(), and is of a > similar nature, except that _longjmp() already exists as a separate > interface. So, at least in the case of longjmp(), it needs to have a > different alias, perhaps __longjmp(). Below is a *very* simplistic patch > to libc that works, but it may make some people's skin crawl. Feedback is > welcome. If there is no correct way to create aliases to function entry > points, then we can do without them, but it will mean that the *jmp() > functions cannot be used in conjunction with thread cleanup handlers when > using LinuxThreads. __longjmp() and __siglongjmp() don't bother me at all. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991209064256.B34152>