From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
Cc: | Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Igor <igor(at)carcass(dot)ath(dot)cx>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: server-side extension in c++ |
Date: | 2010-06-02 14:06:07 |
Message-ID: | 201006021406.o52E67L22129@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Craig Ringer wrote:
> See the attached demo (pop all files in the same directory then run "make").
>
>
> > I would have
> > imagined that ultimately, the call to the Pg C function must return,
> > and therefore cannot affect stack unwinding within the C++ part of the
> > program.
>
> That's the whole point; a longjmp breaks the call chain, and the
> guarantee that eventually the stack will unwind as functions return.
>
> It's OK if you setjmp(a), do some work, setjmp(b), longjmp(a), do some
> work, longjmp(b), return.
>
> My understanding, which is likely imperfect, is that Pg's error handling
> does NOT guarantee that, ie it's quite possible that a function may call
> longjmp() without preparing any jmp_env to "jump back to" and therefore
> will never return.
You are correct that a longjump() jumps back to the query entry loop,
hopping over any user-defined C or C++ functions in the call stack, and
you are right that if we were just using longjump() without unwinding
C++ calls, we would be OK using non-POD structures.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is going to be here forever. +
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Wilcox | 2010-06-02 14:08:18 | Re: Out of Memory and Configuration Problems (Big Computer) |
Previous Message | Stephen Frost | 2010-06-02 14:05:52 | Re: postgres authentication against Windows Domain |