> OK, but what if I want one thread per CPU?
>
> So if I have a 4 CPU rig and 400 connections, I want to
> have 4 threads and 100 connections per thread.
> But if the load increases to 600 connections, I want to
> have 4 threads and 150 connections per thread.
This si not a winsock or TCP/IP compo
>From borland.public.delphi.internet.winsock:
Francois wrote:
> The server component will create a new thread as the previous one reached
> the maximum number of client you've setup. It is the OS which schedule the
> available CPUs to the threads in the ready state.
OK, but what if I want one
> Any idea ?
Just compared function FindFirst of D7 and D10, they are different.
D10
const
faSpecial = faHidden or faSysFile or faDirectory;
D7
const
faSpecial = faHidden or faSysFile or faVolumeID or faDirectory;
Also const faVolumeID is tagged as deprecated in D10, and commented "not used
Is this considered stable enough for commercial use and does it have BDS
2006 project files for C++Builder 2006 use?
Thank you.
--
Albert Wiersch
AI Internet Solutions
[EMAIL PROTECTED]
http://www.htmlvalidator.com/
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROT
To all subscribers:
1) Please do not use HTML or RTF messages in the list. Use only plain/text
messages (by default Outlook uses HTML ! You must change the setting).
When replying, be sure to use plain/text. If someone email to list
accidently NOT in plain text and if you reply to it,
This one contains some small fixes by Arno and myself.
Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html
--
[EMAIL PROTECTED]
http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsoc
In ICS-V6, there is a function IsDirectory located in OverbyteIcsHttpSrv.
IsDirectory is based on SysUtils.FindFirst. So far so good.
The problem is the behaviour difference between D7 and D2006. When supplying
"c:" as root directory, D2006 list it as a directory because IsDirectory
returns TRUE.
> I am using ICS's Ftp Server component and I get "operation would block"
> message from my application on some computers ( my application is a
> cafe control software). How can I solve this problem.
Would you please describe the situation where you get "operation would
block" ? This is perfectly
Hi Peter
Thank you for your reply
Last paragraph in text file you sent me may be my problem.
You wrote
(If you decide to use non-blocking sockets in your application, it’s
important to keep in mind that you must check the return value from every
read and write operation, since it is possible
This refers to blocking sockets or blocking function calls.
I attached a description of the problem.
Cheers,
Peter
On Tue, 13 Jun 2006 12:44:03 +0200, DZ-Jay <[EMAIL PROTECTED]> wrote:
Hello:
I received this question directly from an ICS user. I suggested he
subscribe to this list, bu
> Would that work principally?
I think so.
Better performance can also be achieved using a pool of TWSocket to avoid
destroying each instance when connection is closed and recreating a new one
when the next connection is available. Same for the threads.
--
[EMAIL PROTECTED]
http://www.overbyte.be
Francois PIETTE wrote:
>> Also I think that V6 should get a secure method to move a
>> socket to a different thread context. Required only in multi-threaded
>> after Accept a client connection.
>
> In that situation, the most secure method is to do it when we get the
> socket handle from Accept()
Hello:
I received this question directly from an ICS user. I suggested he
subscribe to this list, but in the meantime, can anybody shed some
light on the problem stated?
Thank you,
dZ.
On Jun 13, 2006, at 03:11, AKINSOFT Programlama wrote:
-
13 matches
Mail list logo