> >> Aside from any reduction in the need > >> for volatile, this might actually perform slightly better, because > >> sigsetjmp() is a system call on some platforms. There are probably > >> few cases where that actually matters, but the one in pq_getmessage(), > >> for example, might not be entirely discountable. > > > > Hm. How would you implement PG_TRY_WITH_CLEANUP without a sigsetjmp()? > > Posit: > > struct cleanup_entry { > void (*callback)(void *); > void *callback_arg; > struct cleanup_entry *next; > }; > cleanup_entry *cleanup_stack = NULL; > > So PG_TRY_WITH_CLEANUP(_cb, _cb_arg) does (approximately) this: > > { > cleanup_entry e; > cleanup_entry *orige; > e.callback = (_cb); > e.callback_arg = (_cb_arg); > e.next = cleanup_stack; > orige = cleanup_stack; > cleanup_stack = &e; > > And when you PG_END_TRY_WITH_CLEANUP, we just do this: > > cleanup_stack = orige; > }
Hm. Not bad. [ponder] I guess we'd need to tie it into PG_exception_stack levels, so it correctly handles nesting with sigsetjmp locations. In contrast to sigsetjmp() style handlers we can't rely on PG_CATCH cleaning up that state. I wonder how hard it is to make that reliable for errors thrown in a cleanup callback. Those certainly are possible in some of the PG_CATCHes we have right now. > And before doing sigsetjmp to the active handler, we run all the > functions on the stack. There shouldn't be any need for volatile; the > compiler has to know that once we make it possible to get at a pointer > to cb_arg via a global variable (cleanup_stack), any function we call > in another translation unit could decide to call that function and it > would need to see up-to-date values of everything cb_arg points to. > So before calling such a function it had better store that data to > memory, not just leave it lying around in a register somewhere. Given that we, at the moment at least, throw ERRORs from signal handlers, I don't think that necessarily holds true. I think we're not that far away from getting rid of all of those though. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers