Mailing List Archive

Hi,

Alvaro Lopez Ortega wrote:

>>> * Threads support (*2)
>>>
>>>
>>I develop a multithread proxy (not free software), so I know a little
>>about this matter, I was even thinking about programming this feature
>>for quite some quite. I have to make sure that functions used are
>>thread-safe (don't use global vars, if two thread want to write in the
>>same sttructure at the same time, syncronization...).
>>
>>
>>
>>>(*2) - We didn't speak about this issue before, but it's a very important
>>>item in the list. It'll add SMP and multi-threading support to
>>>Cherokee.. at this moment, Cherokee just only runs in a single procesor
>>>(thread) but it should change to get advantage of the new micros.
>>>
>>>
>>absoultely, I agree with you, quite important.
>>
>>
>
> The idea is to add a little thread pool. Cherokee will work in, more or less,
>the same way. The main change is that if it has a few threads it will get
>some performance advantages in new machines [1]. :-) Each thread will work
>with some connections. Due the design, I think It won't be very hard to do:
>everything is a object, and there aren't global variables.
>
>
I agree with you, it seems not difficult to implement. here comes my idea:

cherokee
thread 1
cherokee
thread 2
connection queue ---> ...
cherokee
thread 3

Every cherokee thread has its own pool of descriptors, and do accept()
to get a connection
from the queue and add it to its pool. So there will be only one mutual
exclusion section, the accept section.

Well, anyway I don't want to rush with this matter, I need some time to
think about it :-), but I also need time to study (exams up to 24th
June), so I'll spawn some threads in my head to get everythin working at
the same time :-))).

There's a comparison between server implemented by using fork, thread
and pool in this book: http://www.kohala.com/start/unpv12e.html
(unix network programming, stevens), and the conclusion is that the
fastest is the pool implentation and so closer is the threaded one.

I think it's a must to have. do you have any book which you love about
this matter?

>
> The most important thing is make it with a very little number of mutual
>exclusion sections (to get a good performance). :-)
>
>
> 1.- http://www-106.ibm.com/developerworks/linux/library/l-htl/
>
>
>
cheers,
Pablo

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 14 June 2003 21:39, pablo neira wrote:

> > The idea is to add a little thread pool. Cherokee will work in, more or
> > less, the same way. The main change is that if it has a few threads it
> > will get some performance advantages in new machines [1]. :-) Each
> > thread will work with some connections. Due the design, I think It won't
> > be very hard to do: everything is a object, and there aren't global
> > variables.
>
> I agree with you, it seems not difficult to implement. here comes my idea:
>
> cherokee
> thread 1
> cherokee
> thread 2
> connection queue ---> ...
> cherokee
> thread 3
>
> Every cherokee thread has its own pool of descriptors, and do accept()
> to get a connection
> from the queue and add it to its pool. So there will be only one mutual
> exclusion section, the accept section.

Ummm.. I'm not sure about this.
I think it add some overhead to the server. Why many process should add the
same thing (accept new connections)? Has it some advantage? :-??

My idea is that the main process do the accept() time to time (in the same
way as it working today) and bring it to some of the threads.

> Well, anyway I don't want to rush with this matter, I need some time to
> think about it :-), but I also need time to study (exams up to 24th
> June), so I'll spawn some threads in my head to get everythin working at
> the same time :-))).

Grrrrrr.. We all have exams. We're going to start July with too much to
code. ;-))))

(BTW, have luck with the exams ;)

> There's a comparison between server implemented by using fork, thread
> and pool in this book: http://www.kohala.com/start/unpv12e.html
> (unix network programming, stevens), and the conclusion is that the
> fastest is the pool implentation and so closer is the threaded one.

We'll have a mix between both. 95% of the work with the poll() method and
the rest using threads to support SMP and hyper-threading. :-)

> I think it's a must to have. do you have any book which you love about
> this matter?

I have the Stevens one, but I don't like it at all '':-)

- --
Greetings, alo.
http://www.alobbs.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+64jEVRSCNxlNnu0RAuaEAJwJcNw9SEMHbxJlz6baEo5kBz0rfACgnqGj
5bIU2SWbEypmDVJmzzRiRq0=
=FfO6
-----END PGP SIGNATURE-----

On Sat, 14 Jun 2003 19:47:47 +0200 Alvaro Lopez Ortega <alvaro@alobbs.com> wrote:
> The idea is to add a little thread pool. Cherokee will work in, more or less,
> the same way. The main change is that if it has a few threads it will get
> some performance advantages in new machines [1]. :-) Each thread will work
> with some connections. Due the design, I think It won't be very hard to do:
> everything is a object, and there aren't global variables.
>
> The most important thing is make it with a very little number of mutual
> exclusion sections (to get a good performance). :-)
>
>
> 1.- http://www-106.ibm.com/developerworks/linux/library/l-htl/
>


The idea of thread-support sounds cool. I often wondered about that tiny and fast
webservers which are fast for one cpu but don't scale with more cpus 'cause of that
static concept.

I just hope, that you don't go the way of apache or similar webservers. adding threads
where each thread would only serve one client. It would be much better to either define
the number of threads in the configuration to match the number of cpus or even (if its possible, I don't know)
autodetect the number of cpus to only spawn that number of threads.



Thomas

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 15 June 2003 14:04, Thomas Seifert wrote:

Hi Thomas!

> The idea of thread-support sounds cool. I often wondered about that tiny
> and fast webservers which are fast for one cpu but don't scale with more
> cpus 'cause of that static concept.

Yeah.. ':-) this problem affect to all tiny servers: thttpd, boa, etc. But
well, we're going to solve it in a few :-)

> I just hope, that you don't go the way of apache or similar webservers.
> adding threads where each thread would only serve one client. It would be
> much better to either define the number of threads in the configuration to
> match the number of cpus or even (if its possible, I don't know) autodetect
> the number of cpus to only spawn that number of threads.

That is *exactly* the idea! :-)))

At first moment, the number of thread could be a parameter in the
configuration file, and work in the autodectection from that moment. :))

- --
Greetings, alo.
http://www.alobbs.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+7EwOVRSCNxlNnu0RAv94AJ9tezmDBI+jcYYXdpBlxJWbvmWzyACeOQy0
F1GJ2JncNCU5Ubbz2kU0KRM=
=Pff/
-----END PGP SIGNATURE-----

On Sun, 15 Jun 2003 12:04:21 +0000, Thomas Seifert wrote:

> I just hope, that you don't go the way of apache or similar webservers. adding threads
> where each thread would only serve one client. It would be much better to either define
> the number of threads in the configuration to match the number of cpus or even (if its possible, I don't know)

Yep, it's posible. Look at:

http://cvs.samba.org/cgi-bin/cvsweb/~checkout~/distcc/src/ncpus.c?rev=1.12&content-type=text/plain

> autodetect the number of cpus to only spawn that number of threads.

Cheers :)

--
.''`. Why is a cow? Mu. (Ommmmmmmmmm)
: :' :
`. `' Proudly running Debian GNU/Linux Sid (Kernel 2.4.21) on Ext3
`- http://laurel.datsi.fi.upm.es/~rpons/

El Se?or es mi pastor, nada me falta, en verdes praderas me hace recostar.
Me conduce hacia fuentes tranquilas y repara mis fuerzas.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 15 June 2003 14:20, Ramon Pons Vivanco wrote:

> > I just hope, that you don't go the way of apache or similar webservers.
> > adding threads where each thread would only serve one client. It would be
> > much better to either define the number of threads in the configuration
> > to match the number of cpus or even (if its possible, I don't know)
>
> Yep, it's posible. Look at:
>
> http://cvs.samba.org/cgi-bin/cvsweb/~checkout~/distcc/src/ncpus.c?rev=1.12&
>content-type=text/plain

Commited, thank rpons :-)
http://cvs.alobbs.com/cgi-bin/cvsweb/cherokee/src/ncpus.c?rev=1.1&content-type=text/x-cvsweb-markup

- --
Greetings, alo.
http://www.alobbs.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+7GMfVRSCNxlNnu0RAll8AJwPVCnY007X3unXRCBHTdv71+uvDQCfQoNC
VdJLN5iCzQC9+qBjbedUuHg=
=mSNh
-----END PGP SIGNATURE-----

Thomas Seifert wrote:

>On Sat, 14 Jun 2003 19:47:47 +0200 Alvaro Lopez Ortega <alvaro@alobbs.com> wrote:
>
>
>> The idea is to add a little thread pool. Cherokee will work in, more or less,
>>the same way. The main change is that if it has a few threads it will get
>>some performance advantages in new machines [1]. :-) Each thread will work
>>with some connections. Due the design, I think It won't be very hard to do:
>>everything is a object, and there aren't global variables.
>>
>> The most important thing is make it with a very little number of mutual
>>exclusion sections (to get a good performance). :-)
>>
>>
>> 1.- http://www-106.ibm.com/developerworks/linux/library/l-htl/
>>
>>
>>
>
>
>The idea of thread-support sounds cool. I often wondered about that tiny and fast
>webservers which are fast for one cpu but don't scale with more cpus 'cause of that
>static concept.
>
>I just hope, that you don't go the way of apache or similar webservers. adding threads
>where each thread would only serve one client.
>
This is just the way I used to do it, but I think this is ok if you
decide to implement a multithread server from scratch and you don't care
so much about speed (because as I read, thread servers are always slower
than "pooled" servers). I agree with you, spawning a thread for every
connection done doesn't fit to cherokee.

>It would be much better to either define
>the number of threads in the configuration to match the number of cpus or even (if its possible, I don't know)
>autodetect the number of cpus to only spawn that number of threads.
>
>
>
>Thomas
>_______________________________________________
>Cherokee mailing list
>Cherokee@alobbs.com
>http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee
>
>
>

Alvaro Lopez Ortega wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Sunday 15 June 2003 14:04, Thomas Seifert wrote:
>
> Hi Thomas!
>
>
>
>>The idea of thread-support sounds cool. I often wondered about that tiny
>>and fast webservers which are fast for one cpu but don't scale with more
>>cpus 'cause of that static concept.
>>
>>
>
> Yeah.. ':-) this problem affect to all tiny servers: thttpd, boa, etc. But
>well, we're going to solve it in a few :-)
>
>
>
>>I just hope, that you don't go the way of apache or similar webservers.
>>adding threads where each thread would only serve one client. It would be
>>much better to either define the number of threads in the configuration to
>>match the number of cpus or even (if its possible, I don't know) autodetect
>>the number of cpus to only spawn that number of threads.
>>
>>
>
> That is *exactly* the idea! :-)))
>
> At first moment, the number of thread could be a parameter in the
>configuration file, and work in the autodectection from that moment. :))
>
Ok, I got it but still in doubt. more questions...

Are those threads going to share the pool of descriptor and list of
active connections or they will have their own one?

if they share the pool/list, there will be a mutex section where you
change the state of every connection and when you purge a descriptor. So
better if every thread has its own pool/list, hasn't it?

Alo said:"My idea is that the main process do the accept() time to time
(in the same way as it working today) and bring it to some of the threads."

So maybe we could use this way. There's a main process which does the
accept() and add the descriptor to the pool and the connection to the
list of one of the threads in some way (I mean, the main process uses a
fast algorithm, some kind of "load balancing", to add that
descriptor/connection to the poll of one of the threads.

something like...
thread 1
(pool 1/list 1)
main process(accept) -----> thread 2 (pool 2/list 2)
(this process decides thread 3 (pool
3/list 3)
which thread manages ....
the connection)


Of course the number of threads is selected from the config file. This
way, I think there won't be mutex sections, well maybe only we'll need
to use semaphore to syncronize the read ing and writing of the pool/list.

Am I getting closer to the solution or maybe even further? :-)

wait for you feedback.

Pablo :-)