|
Dos Equis - each bottle contains the piss of TWO horses!
====================================
Transvestites - Roberts in Disguise!
====================================
|
|
|
|
|
SledgeHammer01[^] may be your bestest new buddy. 
No, seriously, he may be the go-to guy around here.
|
|
|
|
|
Where do you stand now after 3 hours drinking? If still standing.... 
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^]
|
|
|
|
|
I won't stand for anyone getting falling-down drunk in here.
|
|
|
|
|
I was setting on my comfortable couch, but guess what! drinks make your imagination work better
Genius is one percent inspiration and ninety-nine percent perspiration.
|
|
|
|
|
Do Not mix feeling with dev...
resolute from one another..and don't drink and drive..
Thanks
|
|
|
|
|
Our C# application uses TCP/IP sockets for interprocess communication. I use the Socket class asynchronous methods to process received messages, something like this:
s.BeginReceive(...,OnReceive);
...
void OnReceive(...)
{
lock(...)
{
...
s.BeginReceive(...,OnReceive)
}
...
}I discovered that the OnReceive was being called recursively under heavy traffic conditions, resulting in messages being processed in reverse order for brief periods   . The solution went something like this:
s.BeginReceive(...,OnReceive);
...
void OnReceive(...)
{
lock(...)
{
...
}
...
s.BeginReceive(...,OnReceive)
}The time-reversing version has been in the product since 2008, and I only discovered it a week ago. One petard-wedgie, coming up.
Software Zen: delete this;
|
|
|
|
|
|
My group builds controller applications for our commercial ink-jet printing systems[^]. The apps are structured as a front-end UI application and one or more Windows services. The services can end up running on other machines in the system. Using TCP/IP sockets makes it easy to move services around for hardware or performance reasons.
We also use TCP/IP to communicate with a lot of the hardware, so having a common protocol throughout simplifies things.
Software Zen: delete this;
|
|
|
|
|
Ah I see that makes sense now.
Sounds pretty interesting!
=====
\ | /
\|/
|
|-----|
| |
|_ |
_) | /
_) __/_
_) ____
| /|
| / |
| |
|-----|
|
=====
===
=
|
|
|
|
|
TCP is a great technology to use when you want to avoid all the pitfalls with same-machine process communication or networking technology. Back when I worked in a financial company our software was a 'hub and worker client' type setup (10 or so client processes), each in a different process and potentially on a different machine, sometimes Windows and sometimes Unix/Linux. Using TCP sockets means you don't really have to worry where the clients are.
|
|
|
|
|
Ouch!
Bob Dole The internet is a great way to get on the net.
2.0.82.7292 SP6a
|
|
|
|
|
I think I had exactly this bug in my sockets library at one point and it was really confusing trying to catch it. Particularly as I don't have a load-saturation test rig so it was pretty rare for me (generally it would happen when I was streaming a file or something like that).
|
|
|
|
|
It seems that the sample code given should just put the result into a work queue so that the network IO can be overlapping the actual work without getting out of order...
Kind of reminds me of a mystery when teaching an Intro to C class.
Lab:
Open a file, write 5 lines into the file, close the file.
Result:
The lines were coming out backwards!
Cause:
The fopen() was being called inside the loop.
Line 1 was written (buffered).
open the file again
Line 2 was written (buffered)
etc.
On exit, the handles must have been closed in reverse order so Line 5 flushed first, followed by Line 4, ... Line1.
Buffered IO strikes again.
|
|
|
|
|
englebart wrote: It seems that the sample code given should just put the result into a work queue so that the network IO can be overlapping the actual work without getting out of order...
The sample I provided is a substantial simplification of the actual code, which pretty much does what you suggest.
Software Zen: delete this;
|
|
|
|
|
This only works if you have only two calls to OnReceive() happening at once, no? If you have two threads waiting on the lock, what guarantee do you have that the "correct" thread will be the next one to acquire the lock?
Fred the Ranger
|
|
|
|
|
Member 7931978 wrote: This only works if you have only two calls to OnReceive() happening at once, no
The key here is the BeginReceive call, which tells the .NET socket support to call the OnReceive delegate asynchronously on a thread pool thread when a message is received. In my initial code that has the bug, I was issuing the second BeginReceive call to start receipt of the next message before I'd finished processing the current message. Under high load conditions, this could cause the OnReceive handler to be called recursively. The actual message handling would then be processed in reverse order as the stack unwound.Member 7931978 wrote: what guarantee do you have that the "correct" thread will be the next one to acquire the lock?
The lock in this case was protecting the socket connection, so there is no 'correct' thread per se. The .NET socket support can call the asynchronous delegate on any thread it has available. The lock is essentially a critical section.
Software Zen: delete this;
|
|
|
|
|
Sorry, but this code violates causality... it won't compile.
|
|
|
|
|
That kind of error is funny.
For many years a C++ application worked. It used a non initialized pointer but, for many time, it was always null (calling the right initialization).
One day it simple decided to get garbage.
|
|
|
|
|
I assume this had something to do with IAsyncResult.CompletedSynchronously[^] (possibly derived from Socket.Available[^])?
Interesting because under extreme and consistent load this means that the async loop could cause a StackOverflowException (even with your fixed code); I wonder if there is a way to turn off this 'optimization' without having to resort to:
private void StartAsyncReadLoop()
{
ReadAsyncLoop(null);
}
private void ReadAsyncLoop(IAsyncResult state)
{
try
{
if (state != null)
{
var length = _socket.EndReceive(state);
}
if (state == null || !state.CompletedSynchronously)
_socket.BeginReceive(..., ReadAsyncLoop, null);
else
ThreadPool.QueueUserWorkItem(_ => _socket.BeginReceive(..., ReadAsyncLoop, null));
}
catch (SocketException ex)
{
}
}
I wonder if Socket.UseOnlyOverlappedIO[^] would have an effect on this, considering Overlapped IO is my 'asyncy' than IOCP.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chinese Proverb]
Jonathan C Dickinson (C# Software Engineer)
|
|
|
|
|
Apparently, one of my co-workers found out that the GetTickCount function from the Windows API isn't reliable as it seemed in the first time he used it. The solution, obviously, was to refactor our code base to use a more reliable function, like timeGetTime.
I almost cried when I saw his commit changing a bunch of *.cpp files, with the following code in the beginning of every file:
#undef GetTickCount
#define GetTickCount timeGetTime
Sad thing is, he doesn't take criticism well.
|
|
|
|
|
Stop being such a bore! Don't criticize, teach! ^^
My programming get away... The Blog...
Taking over the world since 1371!
|
|
|
|
|
Even though it hurts my eyes a little, I must say that it does demonstrate some prettydamn good knowledge about how the C/++ compiler goes about things.
At least it didn't go into stdafx.h.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chinese Proverb]
Jonathan C Dickinson (C# Software Engineer)
|
|
|
|
|
Oh indeed, put it in a header file; not the code files. Code files should contain very few directives.
|
|
|
|
|
I think you'll find the technical term is refuctoring.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
