Ticket UUID: | 689100 | |||
Title: | too much per-thread memory/hurd breakage | |||
Type: | Bug | Version: | None | |
Submitter: | xtifr | Created on: | 2003-02-18 22:58:32 | |
Subsystem: | 49. Threading | Assigned To: | andreas_kupries | |
Priority: | 5 Medium | Severity: | ||
Status: | Closed | Last Modified: | 2003-02-20 08:18:24 | |
Resolution: | Fixed | Closed By: | xtifr | |
Closed on: | 2003-02-20 01:18:24 | |||
Description: |
I briefly brough this up on tcl-core. On Unix(like) systems, way too much memory is being allocated for per-thread structures. Basically, some storage is allocated for a filename returned from dirent(), but the amount of space allocated is enough for a full pathname, when only enough for a filename is required. In other words, "PATH_MAX" is used where "NAME_MAX" is what was wanted. The difference is about 3.75k/thread on my Linux box, and might be worse on other systems. Furthermore, POSIX allows a system to not define PATH_MAX if it doesn't have a pathname limit. The Hurd is such a system, so this code breaks on The Hurd (which shouldn't be a major problem, since the code is wrong to begin with). I'm attaching the patch I wrote for Debian's Tcl8.4 package. Comments, criticism and questions welcomed. | |||
User Comments: |
xtifr added on 2003-02-20 08:18:24:
Logged In: YES user_id=25775 Cool, that's much cleaner, thanks. In the future, it might be nice to add a configure test to see if *any* extra memory is required (which it is on solaris, but isn't on glibc-based systems like linux and hurd), but this is definitely good enough for now. hobbs added on 2003-02-20 07:43:53: File Added - 42928: namemax.patch hobbs added on 2003-02-20 07:43:52: Logged In: YES user_id=72656 I had to correct this with the attached patch to the patch which ensures that we have some value defined. Solaris was otherwise choking (it has the BSD-style MAXNAMLEN). Patched in 8.4.2. xtifr added on 2003-02-19 06:02:02: File Added - 42819: thread_memory_patch |