This is the mail archive of the pthreads-win32@sourceware.cygnus.com mailing list for the pthreas-win32 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Question...


I have a question, and I don't know if this is exactly the place to ask
it, as it's more about general pthreads, and not about the Win32
implementation, but here goes...

I am currently working on some multi-user software. Each connection to
the server will have it's own thread that handles socket i/o (tcp/ip
based). So in the end, I end up with x amount of threads, that spend
most all cpu time in select() waiting for activity, since it's
command-based, and people only type so fast... Testing this out, it's
all worked fine, until I attempted opening many connecitions... (50+).
The result is that it kills the system response time. Not just the
server itself, but the whole computer. Am I just plain going about it
the wrong way? Is thread switching to slow to handle this? Even when
they are usually doing nothing but waiting for i/o? If anyone can give
me some insight to speeds and so forth of threading, or maybe point me
to a better place to ask this, I'd be grateful. For this experience, it
was done under RedHat Linux using the pthreads library.

P.S. Yes, it would be more "effecient" to have one process waiting for
i/o, then upon that, spawn off another thread to handle it, but for the
purposes of this software, it appeared to be more logical and powerful
to do it this way.

Thanks ahead of time,
  Keith Jackson

+===============================+
#   Keith A. Jackson            #  (CBP)
+-------------------------------+
#   dshadow@cambridgeoaks.com   #
#   keithj@agvp.com             #
+===============================+

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]