Re: Threads vs Processes

Tom Lane wrote:
> Shridhar Daithankar <shridhar_daithankar@persistent.co.in> writes:
> > We really don't need threads to replace existing functionality. That
> > would be dog work.
>
> No, that's not the point at all.  The problem we are facing at the
> moment with the Windows port is lack of fork(), which means there's
> no way for separate-subprocess backends to inherit variable values
> from the postmaster.  Bruce has been trying to fix that by having the
> subprocesses somehow reload or re-deduce all those variables; which
> is messy, bug-prone, and probably race-condition-prone too.  In a
> threaded implementation it would maybe be relatively easy to initialize
> a new thread's TLS by copying the postmaster thread's TLS, in which case
> a whole pile of as-yet-unwritten Windows-only code won't be needed.

I haven't said much in this thread yet because I wasn't sure what to
say.

I worked 2-3 weeks on Win32 back in March/April, and a few days last
month getting it to compile again, and for the interfaces/clients to run
under Win32.

I haven't had any time to work on the fork/exec, though I now have a few
weeks to spend on it, so it isn't that I have been trying to get
fork/exec working, and failing, it is that I haven't even tried lately.

My plan is to pass a few values to the child via the command line:

    #ifdef EXEC_BACKEND
        Assert(UsedShmemSegID != 0 && UsedShmemSegAddr != NULL);
        /* database name at the end because it might contain commas */
        snprintf(pbuf, NAMEDATALEN + 256, "%d,%d,%d,%p,%s", port->sock, canAcceptConnections(),
                 UsedShmemSegID, UsedShmemSegAddr, port->database_name);
        av[ac++] = pbuf;
    #else

and pass the GUC settings via a special binary file.  (Those are already
in main CVS.)  The other values I plan to regenerate in the child the
same way the postmaster does it at initialization time.  The easy part
of that is that I only have to worry about postmaster variables.  All my
current fork/exec work is marked by #ifdef EXEC_BACKEND in current CVS,
so it can be easily ripped out.

One solution is for me to continue with this in the Win32 CVS version
until I have fork/exec() working on Unix, then test on Win32.  I think
that could be done in a few weeks, if not less.

Another solution, already mentioned, is to use threads and TLS.  This is
what SRA's code uses.  I know SRA wants to contribute that code back to
the community, so I can ask them to see if they are ready to release it.
That would show us all the changes needed to do threading.  Their code
is based on 7.3.X, rather than PeerDirect's which is based on 7.2.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073