[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svnserve could save its PID somewhere

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-06-21 00:28:38 CEST

Tobias Ringström wrote:

> Branko Čibej wrote:
>
>> Shouldn't be hard to do. You still have to catch the signal, then
>> have the main thread simply terminate. The process should wither away
>> once the other threads have exited, I think. But we do need the
>> sighnal handlers. Also, svnserve should reread its config files (if
>> any) if it sees a SIGHUP. That's just common behaviour.
>
> AFAIK, if you exit from main, all threads get terminated.

That may be true on Unix with pthreads, but Windows works differently.
Which means we're in a bit of a fix, because AFAIK APR doesn't abstract
that difference.

> You need to create the threads without making them detached, and then
> call join before returning from main. It's not a big thing, but it
> requires some housekeeping. It would be useful to implement a maximum
> number of clients at the same time, and a timeout for the clients.

You can't do that, because some requests are dependent on each other, so
that the client blocks on _two_ RA sessions (diff and merge will
generate such, for example), but the server can't know for sure which
requests these are. I started implementing thread pools in svnserve
(stopped that because APR condition variables don't work correctly on
Windows), and it turns out you need as many threads as there are active
requests to be safe. The best you can do is set a _minimum_ number of,
and a timeout for, idle threads.

But that's getting ahead of the issue. We should get termination
detection in first, then go on from there. For a threaded server, we
could keep a list of active threads and simply wait for them to
terminate before exiting the server. Maybe even propagate the
termination signal as a cancellation.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 21 00:29:19 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.