search for: pthread_cleanup_pop

...ceptions) there is no need to unwind frame-by-frame, the >>> unwind simply needs to make a single jump to the invoke instruction and >>> restore the context (which in x86 is just 6 registers). >> Not quite. It's also necessary to execute all the pending POSIX >> pthread_cleanup_pop() actions. > > POSIX pthread_cleanup_pop() can only be called directly from C++/C. > C doesn't haven't exceptions. But it does have pthread_exit(). > So yet again, this is a C++ issue. No, it isn't: The effect of calling longjmp() or siglongjmp() is undefined if...

...t languages that > support exceptions) there is no need to unwind frame-by-frame, the > unwind simply needs to make a single jump to the invoke instruction and > restore the context (which in x86 is just 6 registers). Not quite. It's also necessary to execute all the pending POSIX pthread_cleanup_pop() actions. > It is possible to implement invoke/unwind in such a way that both invoke > *and* unwind are fast, when unwind just unwinds and doesn't perform > any magic behind-the-scenes operations. I don't think so. Not for pthreads, anyway. Andrew.

...is no need to unwind frame-by-frame, the >>>> unwind simply needs to make a single jump to the invoke instruction and >>>> restore the context (which in x86 is just 6 registers). >>> Not quite. It's also necessary to execute all the pending POSIX >>> pthread_cleanup_pop() actions. >> POSIX pthread_cleanup_pop() can only be called directly from C++/C. >> C doesn't haven't exceptions. > > But it does have pthread_exit(). > >> So yet again, this is a C++ issue. > > No, it isn't: > > The effect of calling l...

...e restoring signals, > and calling pthread cleanup routines? The front-end needs to ensure that there is an appropriate invoke that runs the pthread cleanup routines in the unwind block. > In other words does the dwarf unwinder do nothing other than unwind, > and was all that stuff about pthread_cleanup_pop() actions just a > red-herring? I think it was a red-herring, but I don't know anything about pthread_cleanup_pop. Ciao, Duncan.

...support exceptions) there is no need to unwind frame-by-frame, the >> unwind simply needs to make a single jump to the invoke instruction and >> restore the context (which in x86 is just 6 registers). > > Not quite. It's also necessary to execute all the pending POSIX > pthread_cleanup_pop() actions. POSIX pthread_cleanup_pop() can only be called directly from C++/C. C doesn't haven't exceptions. So yet again, this is a C++ issue. > >> It is possible to implement invoke/unwind in such a way that both invoke >> *and* unwind are fast, when unwind just unwin...

> Yes. Wasn't that obvious? Sorry, I don't understand what point you're > trying to make. I noticed that some people (not you) seem to think that the dwarf unwinder knows special things about signals, pthread_cleanup_pop and whatnot. I was just trying to say that it does not: all this stuff is covered by the standard exception handling concepts. Ciao, Duncan

...d calling pthread cleanup routines? > > The front-end needs to ensure that there is an appropriate invoke that > runs the pthread cleanup routines in the unwind block. > >> In other words does the dwarf unwinder do nothing other than unwind, >> and was all that stuff about pthread_cleanup_pop() actions just a >> red-herring? > > I think it was a red-herring, but I don't know anything about > pthread_cleanup_pop. For avoidance of doubt: pthread_cleanup_pop() is nothing special, it's just an example of a cleanup handler. Cleanups are very similar to exception h...

...0:09 AM, Duncan Sands<baldrick at free.fr> wrote: >> Yes.  Wasn't that obvious?  Sorry, I don't understand what point you're >> trying to make. > > I noticed that some people (not you) seem to think that the dwarf > unwinder knows special things about signals, pthread_cleanup_pop > and whatnot.  I was just trying to say that it does not: all this > stuff is covered by the standard exception handling concepts. I for one am glad you made that comment. I've been struggling until the other day to understand just what the dwarf unwinder did and how it did it and what...

...wind frame-by-frame, the >>>>> unwind simply needs to make a single jump to the invoke instruction and >>>>> restore the context (which in x86 is just 6 registers). >>>> Not quite. It's also necessary to execute all the pending POSIX >>>> pthread_cleanup_pop() actions. >>> POSIX pthread_cleanup_pop() can only be called directly from C++/C. >>> C doesn't haven't exceptions. >> But it does have pthread_exit(). >> >>> So yet again, this is a C++ issue. >> No, it isn't: >> >> The e...

Hi Andrew, > pthread_cleanup_pop() is nothing special, it's just an example of a > cleanup handler. Cleanups are very similar to exception handlers, but > with one small difference: they do some work and then call > _Unwind_Resume() which continues unwinding. The unwinder itself > doesn't know anything about...

...ception"? Is it entirely the front-end or is dwarf unwinding doing some extra work (other than a few unecessary register restores), like restoring signals, and calling pthread cleanup routines? In other words does the dwarf unwinder do nothing other than unwind, and was all that stuff about pthread_cleanup_pop() actions just a red-herring? Mark. > > Ciao, > > Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >

Hi Mark, > You are confusing stopping the unwinding at *some* levels or at *all* > levels. > Eg. > invoke > call > call > invoke > call > call > unwind the dwarf unwinder only stops and runs user code at the invokes. It does restore registers and so forth at every stack frame. This is extra work done at unwind time that reduces the cost

...ame, the >>>>>> unwind simply needs to make a single jump to the invoke instruction and >>>>>> restore the context (which in x86 is just 6 registers). >>>>> Not quite. It's also necessary to execute all the pending POSIX >>>>> pthread_cleanup_pop() actions. >>>> POSIX pthread_cleanup_pop() can only be called directly from C++/C. >>>> C doesn't haven't exceptions. >>> But it does have pthread_exit(). >>> >>>> So yet again, this is a C++ issue. >>> No, it isn't: >&g...

Duncan Sands wrote: >> pthread_cleanup_pop() is nothing special, it's just an example of a >> cleanup handler. Cleanups are very similar to exception handlers, but >> with one small difference: they do some work and then call >> _Unwind_Resume() which continues unwinding. The unwinder itself >> doesn't know...

...typedef ptw32_handle_t pthread_t; The configure test to check if pthreads is available is: int main () { pthread_t th; pthread_join(th, 0); pthread_attr_init(0); pthread_cleanup_push(0, 0); pthread_create(0,0,0,0); pthread_cancel(0); pthread_cleanup_pop(0); ; return 0; } It's assuming a pthread_t could be equal to 0 (an int) which fails when building with MinGW. I changed the code as follows and it at least causes configure to find my pthread library. pthread_t th; pthread_join(th, 0); pthread_attr_init(0); pthread_...

Nick Johnson wrote: >> probably there should be a switch to choose whether codegen should turn >> unwind/invoke into dwarf or setjmp/longjmp style code. It seems to me that there is an implicit, and undocumented, assumption that unwinding needs to handle stack-allocated objects. In languages without stack-allocated objects (ie. most languages that support exceptions) there is no

> probably there should be a switch to choose whether codegen should turn > unwind/invoke into dwarf or setjmp/longjmp style code. There is, but it happens before codegen and is slow. -enable-correct-eh-support will translate invoke/unwind into setjmp/longjmp pairs for the correct behavior. See: http://llvm.org/docs/Passes.html#lowerinvoke Nick > > Ciao, > > Duncan. >

...3/buffer.c Sat Oct 5 16:25:43 2002 @@ -256,6 +256,10 @@ UNLOCK_MUTEX(buf->mutex); } + + /* execute the last pending actions (after the data positions) */ + /* THIS COULD BE UNSAFE, I REALLY DON'T KNOW */ + execute_actions(buf, &buf->actions, buf->position); pthread_cleanup_pop(1); DEBUG("exiting buffer_thread_func"); -------------- next part -------------- diff -urN -X diff.ignore ogg123.orig/format.h ogg123/format.h --- ogg123.orig/format.h Sat Oct 5 16:22:17 2002 +++ ogg123/format.h Sat Oct 5 16:28:39 2002 @@ -22,6 +22,7 @@ #include "transport.h&qu...