Re: [pgsql-hackers-win32] Win32 signal code - first try

Поиск
Список
Период
Сортировка
От Claudio Natoli
Тема Re: [pgsql-hackers-win32] Win32 signal code - first try
Дата
Msg-id A02DEC4D1073D611BAE8525405FCCE2B55F271@harris.memetrics.local
обсуждение исходный текст
Список pgsql-hackers

> > > 1. setjmp/longjmp stack manipulation (i.e. ELOG)
> > 
> > Wrote a small program to check this out. As we 
> > hoped/assumed/expected, it looks just fine.
> Great!
> Just checking - we're talking doing this from inside a user APC, right?

Yes, of course! :-)

[From a user APC executing on the main thread.]



> > Magnus, are you working on a second run at this stuff?
>
> Not right this moment, but I hope to do that sometime this weekend. (No
time until then). 

Tell me about it [sigh].


> A thought there. If we go with the "select loop" version you had tried
> out and just poll (select() with short timeout, poll, loop..), do we
> actually *need* the APCs *at all*? Or should we go with a pure-polling
> solution? (With signals delivered on a separate thread as we discussed,
> of course) The only advantage we gain by the APCs is that they will stop
> the "Ex functions", no? (It's not much extra code to put it in there,
> but if we don't need it..)

Hmmm, not sure. Possibly we can, although it depends on where else we  might
end up needing to "wait". I'd be unreluctant to undo your good work on this
until we are sure it is safe to...

Cheers,
Claudio



--- 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Brusser
Дата:
Сообщение: Postgres v.7.3.4 - Performance tuning
Следующее
От: Tom Lane
Дата:
Сообщение: Re: set search_path and pg_dumpall