Hello,
We have a problem with an application that have 2 threads, when we try to
send 2 different messages by 2 thread using 2 instances of twSocket V5.25.
Each thread got their own socket connection. If the threads are sending at
the same time the application crash with an access violation
[EMAIL PROTECTED] wrote:
>> --- Original Message ---
>>> From: Arno Garrels[mailto:[EMAIL PROTECTED]
>>
>>> You can exchange data between threads the most
> easy is by posting a
>>> message where a pointer to the data is in WParam
> argument. The
>>> pointer can be freed in the custom
VC32 folder is for 32 bit. use VC folder in D1 path.
--
[EMAIL PROTECTED]
The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)
http://www.overbyte.be
- Original Message -
From: "Dave Baxter" <[EMAIL PROTECTED]>
To: "ICS suppo
>--- Original Message ---
>From: Arno Garrels[mailto:[EMAIL PROTECTED]
>
>> You can exchange data between threads the most
easy is by posting a
>> message where a pointer to the data is in WParam
argument. The
>> pointer can be freed in the custom message handler.
> That's indeed the f
DZ-Jay wrote:
> On Nov 29, 2007, at 06:10, Wilfried Mestdagh wrote:
>
>> Hello DZ-Jay,
>>
>> So conclusion is that increasing the backlog does:
>>- decrease the performance for accepting connections
>>- decrease the overall performance of the application
>
> This seems to be the conclusi
Hi All...
This in regards to ICS V5. I think...
I wish to do some legacy stuff, involving Delphi1 (!!)
I'd like to implement a simple UDP conversation, to link an old Win16
app, to a new Win32 only driver via the "LocalHost". (I sort of
understand this way of doing things, I most defiantely
On Nov 29, 2007, at 06:10, Wilfried Mestdagh wrote:
> Hello DZ-Jay,
>
> So conclusion is that increasing the backlog does:
>- decrease the performance for accepting connections
>- decrease the overall performance of the application
This seems to be the conclusion of mine and Huby's tests
Hello DZ-Jay,
So conclusion is that increasing the backlog does:
- decrease the performance for accepting connections
- decrease the overall performance of the application
Also:
- connecting clients should have a range of retry's when refused,
eventually with a random small delay.
For yo
Wait, I'm sorry, I perhaps did not explain correctly: It was taking 5
to 7 minutes for the server to *process* the client's request to
completion, not the connection. My tests, although quick and dirty,
are intended to check the behaviour of my application as a whole, not
just the connection.
Hello Jake,
> attempt to do a Receive, which would return -1 along with the "Would
> Block" winsock error.
You don't have to handle GetLastError. Just check the Error argument in
every event. The 'Would block' thing is internally handled by TWSocket.
If Receive returns 0 or -1 then just exit the
Hello:
In the TWSocket component, I've noticed that if an exception is thrown
within an OnDataAvailable handler
(which is triggered from TCustomWSocket.ASyncReceive() method) they
will be ignored, and only the bMore flag is set to false which will
stop the receive loop.
Since t
Jake Traynham wrote:
>So, it seems that for every time ASyncReceive looped, there would
> still be a message (FD_Read??) being put in the queue to call it
> again, which would call my DataAvailable event again, but there
> wouldn't be any data to read because ASyncReceive had already looped
>
12 matches
Mail list logo
