This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/2] Set default stack size from program environment


My core objection is to adding a magic environment variable that can affect
everybody everywhere.  That just sets off lots of alarm bells and is almost
the antithesis of conservative change.

I recommended adding the API call first because it is a reasonably
conservative change, and it lays groundwork for considering more radical
changes later.  That is still my position.  To be more concrete, here's
what I suggest:

1. Add an API call, with tests, etc.  We can review this on mundane
   technical details of the implementation.  I expect that will go
   quickly and have little difficulty reaching consensual approval.

2. Demonstrate other ideas by writing one or more preload modules that work
   by using this new call.  LD_PRELOAD and /etc/ld.so.preload are existing 
   known quantities that paranoid people already know to be paranoid about.

   This could be the end of it, if whoever wanted this feature in the first
   place is happy enough writing their own preload module to implement it.

   However, I am unlikely to object to having a canonical module that is
   maintained in libc and installed normally by libc, and that works by
   consulting environment variables and/or system-wide configuration files.
   Then use of this could be something like:
	export LD_PRELOAD=${LD_PRELOAD:+${LD_PRELOAD}:}'/$LIB/libthread-stack-config.so'
	export GNU_THREAD_STACK_SIZE=0x1000000
   or similarly for /etc/ld.so.preload and whatever system-wide
   configuration file you want to use.

  Let people use these preload methods for a while in real-world
  situations.  If people come back with complaints that this is
  insufficient, suboptimal, or onerous in some regard, then we can
  reconsider the issue in the context of that real-world experience.

(When I initially suggested splitting up the change into the API call and
the other part, I had not thought of the preload approach.)


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]