This was one of the points I was talking about in the original message.
This way, it's still one session per backend, but uses threads to improve
throughput..."(While one thread is waiting for the disk to respond to an IO request, another processes the last chunk
ofdata)"
This one looks to me like the best idea.
Now that pthreads is pretty much standard on systems (or available),
threading shouldn't be so problematic from a portability standpoint...
Duane
> 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
>
