> ICS V6 create a hidden window for a lot of sockets (there is a constant in
> the source code to define that).
> It also create a different hidden window for each thread because messages
> are dispatched by threads.
my app is a single threaded, dunno if there's other thread running
(like winsock), anyway if Dod says that it's normal than that's ok.
But it seems for every twsocket created there's one handle for each of
them.
> If you mean calling Synchronize, then no they aren't synchronized methods.
> They use a critical section to protect access from different threads. This
> is already existing in V5. There is a conditional compile to have or not
> this critical section. Using a critical section is handy if you use a given
> TWSocket from several thread but it has an impact on performance. So you may
> want to disable it and make sure you never use a TWSocket from another
> thread than the one sevicing his events (creation thread or "attached"
> thread).
as for the "synchronized method" that i ask before, what i mean is, is
it blocking procedure ? I know it should not, but using profiler
(Aqtime4), it has the second most time spent in program. After deeper
inspection, i find that (in this example i'm using
wsocket_synchronized_connect) :
//code snippet
1 if @FConnect= nil then
2 @FConnect := WSocketGetProc('connect');
3 Result := FConnect(s, name, namelen);
//end code
line number 3 is the culprit. But because it's a winsock procedure,
there's nothing i could done about it, except using thread. But since
my app right now is already built with single thread in mind, and i
don't want to mess around with it (the deadline is near) what if i use
a beginthread function to encapsulate a call to wsocket.connect ?
would that be feasible ?
and btw francois, the critical section you mentioned seemed to be on
WSocketGetProc (line #2), not on the wsocket_synchronized_* itself
right ? it seems (at least on my app), the critical section is not
affecting performance at all, because wsocketgetproc only called once
in the beginning (if fconnect is nil), while for the rest of the time
it goes directly to line #3.
regards,
sam
On 9/26/06, Francois Piette <[EMAIL PROTECTED]> wrote:
> > My question is, shouldn't it be that v6 use only
> > one handle ? am i missing something here ?
>
> ICS V6 create a hidden window for a lot of sockets (there is a constant in
> the source code to define that).
> It also create a different hidden window for each thread because messages
> are dispatched by threads.
>
> > also, is send, sendto, and sendstr method a "synchronized method" ?
>
> If you mean calling Synchronize, then no they aren't synchronized methods.
> They use a critical section to protect access from different threads. This
> is already existing in V5. There is a conditional compile to have or not
> this critical section. Using a critical section is handy if you use a given
> TWSocket from several thread but it has an impact on performance. So you may
> want to disable it and make sure you never use a TWSocket from another
> thread than the one sevicing his events (creation thread or "attached"
> thread).
>
> Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html
> --
> [EMAIL PROTECTED]
> Author of ICS (Internet Component Suite, freeware)
> Author of MidWare (Multi-tier framework, freeware)
> http://www.overbyte.be
>
>
> ----- Original Message -----
> From: "samuel" <[EMAIL PROTECTED]>
> To: "ICS support mailing" <[email protected]>
> Sent: Monday, September 25, 2006 10:38 PM
> Subject: Re: [twsocket] For those who have using twsocket for heavy
> traffic..
>
>
> > i've tried ICSv6, but there is something that puzzles me.. On startup i
> > created around 1000 twsocket in to be put in a pool, but when i check it
> > using process explorer (freeware from www.sysinternals.com ), the user
> > handle is more than 1000, and when i create only 1 twsocket, the number of
> > handle is only around 30. My question is, shouldn't it be that v6 use only
> > one handle ? am i missing something here ?
> >
> > also, is send, sendto, and sendstr method a "synchronized method" ?, the
> > reason that i asked this is because it calls realsend, which calls
> something
> > like wsocket_syncrhonized_send in wsocket.pas. I also noticed that
> > wsocket_synchronized_* (replace * with send, connect, etc) is the second
> > procedure beside getmessage that is using the most time (checked using
> > aqtime4 profiler).
> >
> > thx
> >
> > On 9/24/06, Arno Garrels <[EMAIL PROTECTED]> wrote:
> > >
> > > samuel wrote:
> > > > Is there anything else that i miss, that should be noted for high
> > > > performance socket apps ? Please share your experience and thoughts..
> > >
> > > At first you should move to V6. In V6 any TWSocket instances in
> > > a thread use the same, single window. If you run TWSocketServer
> > > it may also help to cache and reuse client TWSocket instances.
> > > Running the listening socket in it's own worker thread _may help
> > > as well if clients frequently get 10061 due to a full listenbacklog
> > > queue.
> > >
> > > Arno Garrels
> > >
> > > --
> > > To unsubscribe or change your settings for TWSocket mailing list
> > > please goto http://www.elists.org/mailman/listinfo/twsocket
> > > Visit our website at http://www.overbyte.be
> > >
> > --
> > To unsubscribe or change your settings for TWSocket mailing list
> > please goto http://www.elists.org/mailman/listinfo/twsocket
> > Visit our website at http://www.overbyte.be
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
>
> --
> To unsubscribe or change your settings for TWSocket mailing list
> please goto http://www.elists.org/mailman/listinfo/twsocket
> Visit our website at http://www.overbyte.be
>
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
