Andrew Chernow <[EMAIL PROTECTED]> writes:
>> Here are the options we see:
>>
>> 1. PQregisterEventProc returns a handle, synchronized counter
>> incremented by libpq. A small table could map handle value to proc
>> address, so register always returns the same handle for a provided
>> eventproc. Only register would take an eventproc, instanceData
>> functions would take this magical handle.
>>
>> 2. string key, has collision issues (already been ruled out)
>>
>> 3. have implementors return a static variable address (doesn't seem all
>> that different from returning a static funcaddr)
>>
>> 4. what we do now, but document loudly that PGEventProc must be static.
>> If it can't be referenced outside the DLL directly then the issue can't
>> arise. If you need the function address for calls to PQinstanceData, an
>> implementor can create a public function that returns their private
>> PGEventProc address.
> Do you have a preference form the list above, or an another idea? If
> not, we would probably implement #1. Although, the simplest thing is #4
> which leaves everything as is and updates the sgml docs with a strong
> warning to implementors.
I think #1 is mostly going to complicate life for both libpq and callers
--- libpq has to deal with generating the handles (threading issues
here) and callers have to remember them somewhere. And it's not even
clear to me that it fixes the problem: wouldn't you get two different
handles if you supplied the internal and external addresses of an
eventproc?
On the whole I vote for #4 out of these. I was just wondering whether
there were any better alternatives, and it seems there's not.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
