RE: [HACKERS] Threads

From: "Ansley, Michael" <Michael(dot)Ansley(at)intec(dot)co(dot)za>
To: "'Thomas Lockhart'" <lockhart(at)alumni(dot)caltech(dot)edu>, Duane Currie <dcurrie(at)sandman(dot)acadiau(dot)ca>, pgsql-hackers(at)postgreSQL(dot)org
Subject: RE: [HACKERS] Threads
Date: 1999-08-03 14:35:35
Message-ID: 1BF7C7482189D211B03F00805F8527F70ED0A6@S-NATH-EXCH2
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Aren't there cases, though, where multi-threading could be used within the
back end design that we have at the moment, for example, to avoid lags
during I/O? So, while the nth block of data is being read from the disk,
the (n-1)th block is being processed by the next process down the line. For
example...
This wouldn't (shouldn't?) break the isolation that currently exists due to
single-process servers.

MikeA

>> > As well, a few have been asking about multi-threading.
>> > Any thoughts?
>>
>> Threads within a client backend might be interesting. imho a
>> single-process multi-client multi-threaded server is just asking for
>> trouble, putting all clients at risk for any single misbehaving one.
>> Particularly with our extensibility features, where users and admins
>> can add functionality through code they have written (or are
>> trying to
>> write ;) having each backend isolated is A Good Thing.
>>
>> istm that many of the cases for which multi-threading is
>> proposed (web
>> serving always comes up) can be solved using persistant
>> connections or
>> other techniques.
>>
>> - Thomas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Samersoff 1999-08-03 14:37:57 Re: [HACKERS] Threads
Previous Message Tom Lane 1999-08-03 14:34:43 Re: [HACKERS] Threads