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

IMO, it's time for a second run of the code, and a functional test which
simulates the command processing loop which should include:

1. setjmp/longjmp stack manipulation (i.e. ELOG)
2. in process/out of process generates signals
3. all thread mechanisms.

Definitely. Magnus, I assume you have an interest in continuing this? (if
not, I'll gladly take it over, but I suspect you'll be wanting to ;-)

In any case, I'll independently see if I can get this mechanism wedged into
my win32 code base, and actually try it within postgres itself (when I get
the chance).

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>

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.

Magnus, are you working on a second run at this stuff?

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>

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?

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).

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..)

//Magnus

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>