| 1 |
On Wed, Dec 14, 2005 at 01:07:53AM +0000, Ciaran McCreesh wrote: |
| 2 |
> On Wed, 14 Dec 2005 00:22:36 +0000 Mike Frysinger <vapier@g.o> |
| 3 |
> | another good reason is that since the segment cannot be mapped |
| 4 |
> | readonly, the memory cannot be shared across multiple processes ... |
| 5 |
> | each will need to have its own copy, thus wasting what could be |
| 6 |
> | significant memory resources. |
| 7 |
> |
| 8 |
> Again, that's a big "could be". |
| 9 |
|
| 10 |
it's more often an "is be" considering the fact we're talking about |
| 11 |
shared library code here. |
| 12 |
|
| 13 |
> We don't avoid marking stable code |
| 14 |
> that, say, mallocs lots of space, then fills it with some calculated |
| 15 |
> numbers (for example, the first million prime numbers), even though a |
| 16 |
> better program would allow for that data to be shared. |
| 17 |
|
| 18 |
no one said that broken code with TEXTRELs cannot be marked stable |
| 19 |
|
| 20 |
they're something to be fixed down the road as time permits |
| 21 |
|
| 22 |
> Oh, and don't accept reasons like "but they don't work if we enable |
| 23 |
> $obscure_voodoo in the compiler" either. If $obscure_voodoo breaks on |
| 24 |
> legitimate TEXTRELs then $obscure_voodoo is broken, not the code using |
| 25 |
> TEXTRELs. |
| 26 |
|
| 27 |
majority of the time, if a build process is generating poor code with |
| 28 |
textrels, it wont work on most architectures. x86 just tends to be |
| 29 |
pretty lenient when it comes to poor code, so no one notices/cares. |
| 30 |
-mike |
| 31 |
-- |
| 32 |
gentoo-dev@g.o mailing list |
Archives