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