Thread performance (was Re: dynamic context transitions)

[samba testing]

[-- Attachment #1: Notification --]
[-- Type: text/plain, Encoding: 7bit, Size: 0.5K --]

This is the Postfix program at host open.hands.com.

I'm sorry to have to inform you that your message
could not be
be delivered to one or more recipients. It's attached
below.

For further assistance, please send mail to
<postmaster>

If you do so, please include this problem report. You
can
delete your own text from the attached returned
message.

                        The Postfix program

<samba-technical at samba.org>: host
dp.samba.org[66.70.73.150] said: 550 Error:
    Message content rejected (in reply to end of DATA
command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Encoding: 7bit,
Size: 0.4K --]

Reporting-MTA: dns; open.hands.com
X-Postfix-Queue-ID: E9DB9BFF6
X-Postfix-Sender: rfc822; lkcl at lkcl.net
Arrival-Date: Thu, 16 Dec 2004 21:17:27 +0000 (GMT)

Final-Recipient: rfc822; samba-technical at samba.org
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; host
dp.samba.org[66.70.73.150] said: 550 Error:
    Message content rejected (in reply to end of DATA
command)

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Encoding: 7bit, Size: 2.9K
--]

From: Luke Kenneth Casson Leighton <lkcl at lkcl.net>
To: tng-technical at samba-tng.org
Cc: Multiple recipients of list SAMBA-TECHNICAL
<samba-technical at samba.org>
Subject: Re: Thread performance (was Re: dynamic
context transitions)
Mail-Followup-To: tng-technical at samba-tng.org,
        Multiple recipients of list SAMBA-TECHNICAL
<samba-technical at samba.org>
X-hands-com-MailScanner: Found to be clean


On Sat, Dec 04, 2004 at 07:03:25PM -0600, Christopher
R. Hertel wrote:

allo chris, long time no hear from :)

> I'm also
> interested to know how the two models differ and how
that impacts
> different kinds of performance.

 i'm also genuinely interested to know if a combined
model of
 the standard, present forking processes followed by
running
 threads in the forked processes [not new] has merit.

 [esp. if the current model is to only run threads,
period, which would
  clearly suffer from the scalability issues noted
already].

 a combined model would, i believe, provide the
benefits of not
 suffering from thread/libc scalability issues that
andrew has very
 helpfully outlined, whilst also at the same time
solving the max-mux
 problem.

 ... btw has anyone ever tried writing a
multi-threaded Win32
 program that opens _more_ than 50 (the maxvcs
parameter ;)
 blocking locks to individual [different] files [that
are locked by
 other programs] , and then also tries to do reads and
writes to
 other files?

 so that'd be about 120 threads, 55 of which do a
blocking lock
 access to 55 files, 55 of which do blocking lock
access to exactly the
 same 55 files, followed by 10 doing random reads and
writes to yet more
 files?

 and running that Win32 program against an NT server.

 i'd be absolutely fascinated to know if the maxvcs
parameter limits the
 number of outstanding blocking locks allowed, thereby
bringing an NT
 server to its knees when there are no more virtual
circuits available
 to serve the 10 random-read-write threads :)

 l.



		
___________________________________________________________ 
Win a castle for NYE with your mates and Yahoo! Messenger 
http://uk.messenger.yahoo.com