[Israel.pm] Building a threaded server using Perl?

Yuval Yaari yuval at windax.com
Mon May 31 00:20:48 PDT 2004


Oron Peled wrote:

>On Sunday 30 May 2004 15:11, Yuval Yaari wrote:
>  
>
>>I also want to emphasise that I'm not looking for OS/kernel solutions.
>>    
>>
>
>Wishfull thinking... see below:
>
>  
>
>>I just want my server to be able to concurrently serve a few clients 
>>instead of iterating over all of them one by one - so if I have 10,000 
>>clients connected, it won't take ages to send them all something
>>    
>>
>
>There is a big difference between "few clients" and >10K clients.
>The reference I sent shows that even OS that live natively on the web
>(Unices and Linux) should resort to special features to handle that
>kind of load.
>  
>
I understand, yet I'm not going to recompile my kernel, adding probably 
some not-so-stable pieces of software (or else they'd come WITH the 
kernel :)), just to squeeze 2 more clients.
I am looking for a way to improve my code to give the maximum that it can.
10,000 was just a figure, but I generally mean any number of users that 
would make IO::Select slow.
I want to write a server that can handle any amount of requests 
seamlessly (from the user's POV), until it reaches system (memory, etc.) 
limits.

>>What I forgot to ask: is there copy-on-write when using threads and 
>>modifying a shared hash?
>>    
>>
>
>You just defined the semantics of fork() on any Unix/Linux in the last 20
>years. Fork() gives you the safely of separate processes but the actuall
>copy of pages is done only when a page is touched (that's why it's only
>in the last ~20 years, since you need hardware support for this).
>  
>
But it comes with a price of eating more RAM.
Forking leads me to another question: should I prefer 
forking/pre-forking over threads?
Any problems modifying 1 main hash in the parent process within child 
processes?
Tips for keeping the copy-on-write effect are welcome :)

>BTW: Even if you don't care about the added safety, note that doing all
>the locking/unlocking stuff in a multi-threaded application does not come
>free and *may* create worse performance than two separate processes with
>their own protected memory spaces. (depending on the specifics of
>application of course).
>  
>
I would take your word for it.
Thus I was asking about forking...

  --Yuval




More information about the Perl mailing list