> > > 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 th
> > 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
> 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.
F
> 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
Claudio Natoli wrote:
> FWIW, in a multithreaded version of postgres I'm fooling around with,
I
> replaced the recv call (where backends spend most of their time
waiting)
> which a select(small timeout)/SleepEx(0) "busy" loop, which calls to
recv
> when ready. Works just fine.
Ok, that makes perfe
