|
OriginalGriff wrote: "Don't like the OS? Use FORTRAN, and change it!"
You've just reminded me of my first ever hack. Back in 1964 or thereabouts at Monash Uni, they had a "state of the art" CDC 3200 to which we were allowed to send decks of punched cards. A day or so later, the deck reappeared, hopefully wrapped in a couple of pages of printout. We mere undergrads were limited to IIRC 30 secs run time, which became a bit of a limit on some of our "foreign orders". So, based on a knowledge of the constant absolute address of blank common and a bit of spelunking (find locations in the OS that changed more or less linearly with time...), I wrote an innocent looking FORTRAN subroutine that reset the job timer if it was close to running out. Oh, the joys of unchecked negative array indexes!
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
I remember investigating one application that tried to jump to an invalid location. That app was innocent. Some other code used COMMON to reach what happened to be that program's current memory location, re-wrote the computer instructions including the said jump statement. The app was just running it's instructions when all of a sudden it wasn't their instruction set anymore.
|
|
|
|
|
#define true false
Never trust those booleans!
|
|
|
|
|
IEnumerable<int> finalMarkRange = Enumerable.Range(73,2);
if(finalMarkRange.Contains((int)Math.Round(finalMark,MidpointRounding.AwayFromZero)))
{
...
}
|
|
|
|
|
That's really much better to understand than
if (finalMark < 74.5 and finalMark >= 72.5) { ... }
Get rid of such complicated math!
|
|
|
|
|
and much slower to execute...
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
|
|
|
|
|
I'm guessing there's a whole series of such things?
|
|
|
|
|
I think his & key was not working other wise he would have used a && to do it. poor guy.
|
|
|
|
|
I recently started working for a new company and found quite a few situations like this:
Thread m_thread = new Thread(new ThreadStart(GenerateTimeLineImage));
m_thread.Start();
m_thread.Join();
I'm no expert on mulithreading but there are so many different (not just brainless copy-paste) of code like that, that it made me wondering is there some hidden magic behind that code that I'm not aware of.
So, what's the difference between that and
GenerateTimeLineImage();
besides obvious performance loss due to creating a pointless thread?
|
|
|
|
|
I dont think you missed the magic here. I think, you are right that the thread is pointless in this sample.
You should speak to the author of this code if hes still in your company.
|
|
|
|
|
He's not, I'm his replacement...
|
|
|
|
|
That's why you are replacing him - you can see it.
|
|
|
|
|
That explains everything
|
|
|
|
|
Yes you are right that this code works synchronously albeit using a separate thread. The coder needs to stand in the corner with a dunce cap on.
Cheers!
"With sufficient thrust, pigs fly just fine."
Ross Callon, The Twelve Networking Truths, RFC1925
|
|
|
|
|
I think that makes sense in a WinForms app -- if GenerateTimeLineImage takes a bit of time, which seems likely.
|
|
|
|
|
It's not a winforms app, but even it were, it still don't make sense. GenerateTimeLineImage is a heavy function but it would still block the UI thread (if that's why you mentioned WinApp) because of the m_thread.Join() there.
|
|
|
|
|
No, not the least. In that case the UI thread would be waiting until the other thread is finally done. Meanwhile the UI would not respond, just as if the task had been done on the UI thread itself.
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
Thread.Join Method
Blocks the calling thread until a thread terminates, while continuing to perform standard COM and SendMessage pumping.
|
|
|
|
|
Does this actually work? (I.e. do your event handlers get called, does the window repaint properly, etc?)
|
|
|
|
|
No. Try the following code - The ui blocks for 10 seconds - i am sure.
private void button1_Click(object sender, EventArgs e)
{
Thread m_thread = new Thread(new ThreadStart(GenerateTimeLineImage));
m_thread.Start();
m_thread.Join();
}
void GenerateTimeLineImage()
{
Thread.Sleep(10000);
}
|
|
|
|
|
OK, I sit corrected. However, maybe the developer often needs to do that with several items:
Thread t1 = ... ; t1.Start() ;
Thread t2 = ... ; t2.Start() ;
...
Thread tn = ... ; tn.Start() ;
Join (t1 ) ;
Join (t2 ) ;
...
Join (tn ) ;
and uses this as a general pattern. :shrug:
In which case I might consider a method that takes a collection of delegates:
private static void
InvokeAll
(
params System.Threading.ThreadStart[] Items
)
{
/* Null checking :D */
System.Threading.Thread[] thread = new System.Threading.Thread [ Items.Length ] ;
for ( int i = 0 ; i < Items.Length ; i++ )
{
if ( Items [ i ] != null )
{
thread [ i ] = new System.Threading.Thread ( Items [ i ] ) ;
thread [ i ].Start() ;
}
}
for ( int i = 0 ; i < thread.Length ; i++ )
{
if ( thread [ i ] != null )
{
thread [ i ].Join() ;
}
}
return ;
}
(Untested)
|
|
|
|
|
The good man heard that he was supposed to start a thread when some task takes longer. He did that. Nobody told him what to do once he got the thread going.
Good soldiers who obey every order rarely make good thinkers
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
The only reason I can imagine doing something like that is if there is a requirement that GenerateTimeLineImage() execute on a non-UI thread, and yet be synchronized to the UI thread that requests the operation.
There are plenty of the opposite circumstance (requesting a UI operation from a worker thread), but this sounds strange.
Software Zen: delete this;
|
|
|
|
|
Or perhaps to protect the UI thread from Exceptions?
|
|
|
|
|
Or perhaps there is another thread that somehow manages these extra threads (e.g., abort them if they take too long).
|
|
|
|