Re: [Grub-develop] CRW

[Doug S. <dou...@se...>]

Well it looks like no matter what a developer does, they cannot do any
worse than forking an instance of the program!

I'm not very happy about this info because I believe my Cistron Radius
server (that I'm running at my ISP) is based upon Livingston's, and that's
how Livingston's Radius server was written.

There's a little difference between the way I described and the way the
netwoking book described it.  I was considering putting the accept() in
it's own thread.  They stuck the accept() in the worker thread and
protected it with a mutex.  I take it they then use that thread to service
the entire connection.  So a worker thread wouldn't run at top speed...it
would have to sometimes wait on network input.  That's even a simpler model
than what I was thinking about.  I think I like their model because my
model relies on some kind of message passing (queues, kernel messages,
shared memory, whatever) and theirs just keeps everything inside the worker
thread that accept()ed the connection.

It's not all that complicated.  I've done this stuff before.  I'm more than
capable of whipping up a program like this if you want to see it.

I might have some code for reading a configuration file laying around,
too...I wonder if I can find that.  Do you need something like that as well?

Speaking of which....how would we submit patches?  We probably shouldn't
use the lists to submit patches in case some folks have a modem connection
to the 'net (which is how I'm working right now...when I'm physically not
at work, I just dial in!).  Do you have a "patch (at) grub (dot) org"
mailbox?  Or perhaps an anonymous ftp server with an incoming directory?  

I know that linux kernel developers just send their patches to the kernel
mailing list (and to Linus).  The big advantage is that their patch is
immediately distributed to all the other developers that will want to
try/test it.  The disadvantages include the fact that it can quickly fill a
mailbox that has a quota on it (mine doesn't, but there are folks that have
quotas on their mailboxes), and there are folks who still dial in to the
internet (like me at my home!), and it's not a real patch management scheme.

Seems like SourceForge would already have some kind of a patch management
scheme in place.  But I don't remember seeing anything like that.  I think
I'll go and look through their feature requests and suggest one if it
hasn't been suggested already.

Doug

At 03:02 PM 8/25/00 -0500, you wrote:
>Doug has a point on the use of prethreaded server rather than creating a
>thread on per connection basis.  And I have thought that option myself.
>
>If you have a web site with millions of requests a day, prethreaded server
>is definately necessary.  However, we are not going to have NEARLY as many
>connections as that.  If we had 100,000 clients distributed, which may be
>enough to index the whole internet every single day, and each one of them
>connected every day with the server -> we would have 100,000 connections,
>which will take up a minute or two in CPU time per day for thread
>creation/destruction (on an average PC).  Creating a new thread is faster
>than fork()ing almost in order of 100 times.
>
>I abandoned the idea of doing a preforked/prethreaded server because it does
>not provide real benefits, and it seemed more complicated to create.  Plus
>doing a thread-per-connection server may perform with almost identical
>results as prethreaded server (see below).
>
  ... snip the benchmarks (see archives) ...
>
>Give me more feedback on this.
>
>
>Cheers,
>
>igor.
>
>--------------------------------------------------------------
>Igor Stojanovski                                 Grub.Org Inc.
>Chief Technical Officer                 5100 N. Brookline #830
>                                       Oklahoma City, OK 73112
>oz...@gr...                            Voice: (405) 917-9894
>http://www.grub.org                        Fax: (405) 848-5477
>--------------------------------------------------------------