This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
>>>>> On Thu, 26 Aug 2004 02:24:01 -0700, Ulrich Drepper <drepper@redhat.com> said: Uli> David Mosberger wrote: >> If there are no objections, please apply this patch. Uli> I don't like this. The behavior of longjmp if the starting point is Uli> using the alternate stack while the destination uses the normal stack, Uli> is currently unspecified in POSIX. I've asked for clarification in the Uli> POSIX working group. The result I expect is "don't do it", aka, Uli> unspecified. I wouldn't mind at all if that were the conclusion. I even thought SuS left this unspecified, but upon rereading the spec, it seems SuS explicitly allows this case. Can you let me know when you hear back? Uli> For the unwind/cancellation handling this might not apply. But Uli> it is an implementation decision to use setjmp/longjmp. So, Uli> the solution should be to use special versions of those Uli> interfaces in the nptl implementation. For all platforms but Uli> ia64 the new names are just aliases of the normal code. For Uli> ia64 this heavier code is used. This will also take care of Uli> most of the performance penalties since they don't apply in Uli> general, only in the thread code. Couldn't we avoid the setjmp/longjmp altogether? On ia64, code without unwind info is considered broken and since we unwind anyhow we could have a C cleanup handler for start_thread() at almost zero cost. That would obviate the need for setjmp() in start_thread() and might even speed up thread-creation a little. --david
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |