You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2003/06/25 23:41:45 UTC
Re: svn commit: rev 6355 -
branches/svnserve-thread-pools/subversion/svnserve
On Wed, 2003-06-25 at 19:37, brane@tigris.org wrote:
> Reimplement the threaded server in svnserve to use a thread pool.
Is there any way we could move the functionality of thread.c into
apr-util? I'm uncomfortable with the idea that every network daemon has
to implement this much code just to receive and process requests
efficiently.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 6355 - branches/svnserve-thread-pools/subversion/svnserve
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Wed, 2003-06-25 at 19:48, Branko Čibej wrote:
>
>
>>I dunno. I'm fairly sure some generic parts could go there; for
>>instance, the request queue. Although, there's already apr_queue, which
>>I decided not to use because it has a fixed size. The thread creation
>>logic itself is fairly specific to svnserve, though, because the
>>requests aren't independent (one thread can block until another request
>>is processed -- some diff and merge cases and externals handling are
>>examples).
>>
>>
>
>When you say the logic is specific to svnserve, you mean that svnserve
>requires a policy which not every server needs, right? (Specifically, a
>connection never blocks waiting for a thread to become idle; if no idle
>thread is available, a new one is always created.)
>
Yes, that's right.
>That seems like something you could parameterize in init_threads()
>without adding too much complexity. Though I can see how it would be
>extra work.
>
>
I expect so. But I think it would be worth the trouble, if the APR
people agreed that this is something useful to have in apr-util.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 6355
- branches/svnserve-thread-pools/subversion/svnserve
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2003-06-25 at 19:48, Branko Čibej wrote:
> I dunno. I'm fairly sure some generic parts could go there; for
> instance, the request queue. Although, there's already apr_queue, which
> I decided not to use because it has a fixed size. The thread creation
> logic itself is fairly specific to svnserve, though, because the
> requests aren't independent (one thread can block until another request
> is processed -- some diff and merge cases and externals handling are
> examples).
When you say the logic is specific to svnserve, you mean that svnserve
requires a policy which not every server needs, right? (Specifically, a
connection never blocks waiting for a thread to become idle; if no idle
thread is available, a new one is always created.)
That seems like something you could parameterize in init_threads()
without adding too much complexity. Though I can see how it would be
extra work.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 6355 - branches/svnserve-thread-pools/subversion/svnserve
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Wed, 2003-06-25 at 19:37, brane@tigris.org wrote:
>
>
>>Reimplement the threaded server in svnserve to use a thread pool.
>>
>>
>
>Is there any way we could move the functionality of thread.c into
>apr-util? I'm uncomfortable with the idea that every network daemon has
>to implement this much code just to receive and process requests
>efficiently.
>
>
I dunno. I'm fairly sure some generic parts could go there; for
instance, the request queue. Although, there's already apr_queue, which
I decided not to use because it has a fixed size. The thread creation
logic itself is fairly specific to svnserve, though, because the
requests aren't independent (one thread can block until another request
is processed -- some diff and merge cases and externals handling are
examples).
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org