Jörgen Andersson wrote:
Naerling wrote:
Our company has a product where turning Option Strict On results in probably 1000's of errors
Then you need to start fixring now. ...snip... If it's not the highest priority your company has problems.
FTFY
Jörgen Andersson wrote:
Naerling wrote:
Our company has a product where turning Option Strict On results in probably 1000's of errors
Then you need to start fixring now. ...snip... If it's not the highest priority your company has problems.
FTFY
God I really...REALLY hope that you're just trolling.
Actually, since VB 2008, that's no longer true. The If Operator (without the extra I) The 3 parameter form act like the C# ternary operator ? :
, while the 2 parameter form would be the C# coalesce ??
. But yes, TRWTF is VB.
Yes, I do expect that I will get a timeout for many of the connections. I'm starting with 10 threads, but will probably adjust that number once I get a better idea how the threads perform.
Luc Pattyn wrote:
BTW: using lots of threads for actions that are mostly blocking (waiting on something) rather than computing, is quite wasteful. A better approach could well be to apply asynchronous operations (similar to serving all WinForms Controls from a single thread).
There's a difference? :^) I've always understood "asynchronous programming" to be just a different term for threading.
Essentially, this process would be to collect data from a list of networked machines. Most of the latency comes from locating the machine and then establishing a connection. The threading is so I could continue to process other machined while one is waiting to connect.
I'm looking to add threading support to an application I'm working on, and am looking for advice on how to accomplish this. I have a collection of objects which are updated through a foreach loop. Instead, I'd like to dedicate this to a series of threads, where each object is moved in for processing as the thread becomes available. I've come up with 2 approached on how to do this. Method 1: Using a WaitHandle Give each thread an AutoResetEvent
and rely on the WaitHandle.WaitAny()
method to identify when a thread is finished so a new one can be created. Link: MSDN[^] Pseudocode:
void QueueThreads(IEnumerable myCollection, uint maxThreads)
{
uint usedThreads = 0;
AutoResetEvent[] autoEvents = new AutoResetEvent[Math.Min(maxThreads, myCollection.Count)];
foreach (T myObject in myCollection)
{
if (usedThreads < maxThreads)
{
autoEvents\[usedThreads\] = new AutoResetEvent(false);
//Start a DoWork() thread, passing myObject and autoEvents\[usedThreads\]
usedThreads++;
}
else
{
uint freeThreadID = WaitHandle.WaitAny(autoEvents);
usedThreads--;
//Start a DoWork() thread, passing myObject and autoEvents\[freeThreadID\]
usedThreads++;
}
}
WaitHandle.WaitAll(autoEvents);
}
void DoWork(myObject, AutoResetEvent are)
{
//Do stuff with myObject
//Save results to file/database
are.Set()
}
Method 2: Sharing the enumerator across threads Give each thread access to the enumerator used to iterate over the collection. Each thread stays alive until all items in the collection have been exhausted. Pseudocode:
void QueueThreads(IEnumerable myCollection, uint maxThreads)
{
uint usedThreads = 0;
IEnumerator myCollectionEnum = myCollection.GetEnumerator();
for (uint i = 0; i <= Min(myCollection.Count,maxThreads); i++)
{
//Start a DoWork() thread, passing myCollectionEnum
}
//Find some way to wait until all threads are done
myCollectionEnum.Reset();
}
void DoWork(IEnumerator myColEn)
{
do
{
T myObject;
lock (myColEn)
{
From an old thread posted in late '09[^] Cracks me up everytime.
Josh Gray wrote:
With 15+ years of windows GUI development you should be able to knock up a text viewer quicker than you can knock up your wife.
:laugh: :thumbsup:
PIEBALDconsult wrote:
Therefore == == Equals !
:cool:
Careful. You might get a stack overflow exception. :^)