search for: pthread_cleanup_push

...eanup_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 there have been any calls to pthread_cleanup_push() or pthread_cleanup_pop() made without the matching call since the jump buffer was filled. Andrew.

...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 there >> have been any calls to pthread_cleanup_push() or pthread_cleanup_pop() >> made without the matching call since the jump buffer was filled. >> > > We are not talking about longjmp() or siglongjmp() we are talking about > invoke/unwind! Let's go back a bit. Your claim is that there is no need to unwind fra...

...pthread_t is defined as a struct not an int: typedef struct { void * p; unsigned int x; } ptw32_handle_t; 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...

...s not the case. >> He's right. You can't just jump to the invoke instruction, you must >> also pop any cleanups. This is nothing to do with C++, and it has >> nothing to do with whether a language has stack-allocated objects. > > What cleanups? The ones pushed by pthread_cleanup_push(). > If the C++ front end leaves all these dead objects on the stack and > insists they are cleaned up promptly, then it its responsibility to > clean them up. > It shouldn't burden other front-ends. Like I said, it's nothing to do with C++, or with the C++ front end. > In...

.../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 there > have been any calls to pthread_cleanup_push() or pthread_cleanup_pop() > made without the matching call since the jump buffer was filled. > We are not talking about longjmp() or siglongjmp() we are talking about invoke/unwind! > Andrew. > _______________________________________________ > LLVM Developers mailing li...

...>> He's right. You can't just jump to the invoke instruction, you must >>> also pop any cleanups. This is nothing to do with C++, and it has >>> nothing to do with whether a language has stack-allocated objects. >> What cleanups? > > The ones pushed by pthread_cleanup_push(). pthread_cleanup_push() only exists in C/C++. It is a C library function declared in "pthreads.h" a C header file There are other languages than C/C++. And some of them are easier to use :) > >> If the C++ front end leaves all these dead objects on the stack and >> ins...

...eptions. >>> 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 there >>> have been any calls to pthread_cleanup_push() or pthread_cleanup_pop() >>> made without the matching call since the jump buffer was filled. >>> >> We are not talking about longjmp() or siglongjmp() we are talking about >> invoke/unwind! > > Let's go back a bit. Your claim is that there is n...

...ial destructors on the stack which means calling a function will > be an invoke which will require the function to have a personality. In > C? It's pretty rare. You'd need something like __attribute__((cleanup)) > to do it, the most common source of this will be something > like pthread_cleanup_push. If I recall correctly, Julia sets the > personality on functions regardless of whether or not there are any > invokes, they need the AsmPrinter to scribble something down. I can't > say for other languages (Rust, etc.). From what I understand, Swift > doesn't use landingpad f...

...ch means calling a function will >>> be an invoke which will require the function to have a personality. In >>> C? It's pretty rare. You'd need something like __attribute__((cleanup)) >>> to do it, the most common source of this will be something >>> like pthread_cleanup_push. If I recall correctly, Julia sets the >>> personality on functions regardless of whether or not there are any >>> invokes, they need the AsmPrinter to scribble something down. I can't >>> say for other languages (Rust, etc.). From what I understand, Swift >>&...

Andrew Haley wrote: > Mark Shannon wrote: >> 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. >> >>

> > Let's go back a bit.  Your claim is that there is no need to unwind > frame-by-frame, an unwind simply needs to make a single jump to an > invoke instruction and restore the context (which in x86 is just 6 > registers).  (This is, more or less, what longjmp() does.)  Duncan Sands > explained to you why that wouldn't work, saying "if you throw an > exception

...>>>>> be an invoke which will require the function to have a personality. In >>>>> C? It's pretty rare. You'd need something like __attribute__((cleanup)) >>>>> to do it, the most common source of this will be something >>>>> like pthread_cleanup_push. If I recall correctly, Julia sets the >>>>> personality on functions regardless of whether or not there are any >>>>> invokes, they need the AsmPrinter to scribble something down. I can't >>>>> say for other languages (Rust, etc.). From what I und...

> On 2015-Oct-12, at 10:41, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > > > Vedant Kumar wrote: >>>> That's a neat idea. To summarize: make Function have 3 optional operands. (For context -- Function currently has 1 optional operand, and my proposal is to move to 0.) >>>> >>>> Could someone else chime in on what

Mark Shannon wrote: > 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

On 7/16/19 10:39 AM, Eric Blake wrote: > On 7/16/19 10:04 AM, Richard W.M. Jones wrote: >> The API changes from: >> >> int nbd_add_close_callback (struct nbd_handle *h, >> nbd_close_callback cb, >> void *user_data); >> >> to: >> >> int nbd_add_close_callback (struct nbd_handle