|
So I was fixing my Midi lib's streaming Send() routine to work with large sysex messages and generally be more efficient.
I get called back on send completion - from a different thread. However, list here is never touched again. I just hang on to the enumerator. The enumerator doesn't get touched outside the callback once its filled, and the callback never happens until its filled, so it's "safe" threadwise.
I need to keep the enumerator around so I have a member var called _sendQueue and to be safe I always do Interlocked operations when writing it.
Interlocked.Exchange(ref _sendQueue , list.GetEnumerator());
Anyway, the above succeeds, but a bit later when I'm packaging it for sending, I call _sendQueue.Current to get the current event and it returns null frome Current!!!
There are never nulls in that list I built.
I instead replaced the code above with this:
var e = list.GetEnumerator();
Interlocked.Exchange(ref _sendQueue , e);
And it works.
For the life of me, I have no idea why. I'm about to dive into the IL out of curiosity but I don't think it's going to tell me much.
There have been a lot of oddities in writing this MIDI code, but the above takes the cake.
Real programmers use butterflies
|
|
|
|
|
Might it be a scoping problem? "e" has a scope that is larger than the enumerator received from the .GetEnumerator() call.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
except that the scope is the same, or it should be for the duration of that call? The routine returns immediately after that, without doing anything else except calling a method that takes no parameters and returns no value.
furthermore it's not like the enumerator stored in e/_sendQueue is failing at all in terms of accessing it - it's that the Current member is returning null so the failure is relatively far downstream from this.
I'm stumped.
Real programmers use butterflies
|
|
|
|
|
".Current" will be null if you haven't done a .MoveNext or something else to traverse it. If you do use MoveNext then check its return value is true, as if you're doing something under the covers to alter the list (such as remove an item from it) but not using the proper methods then the enum and list will get out of sync and you'll get null from Current, but in that instance MoveNext will have returned false.
|
|
|
|
|
actually it's supposed to throw if you haven't moved yet, but in this i have.
Real programmers use butterflies
|
|
|
|
|
That's not my experience. Of List<T> anyway, you didn't mention what types you are using.
|
|
|
|
|
the type is a reference type known as MidiMessage.
If List<T>'s enumerator doesn't throw on the first fetch of Current before calling MoveNext() then I promise you it's a bug. It should fail with (IIRC) InvalidOperationException
Real programmers use butterflies
|
|
|
|
|
|
i stand corrected
Real programmers use butterflies
|
|
|
|
|
I've got this idea rolling around in my head - building a rig that provides a server and four players for playing quake 1, 2, 3, and 4.
The "box" will contain a raspberry pi 4 (8gb) to serve as a dedicated server that will run all four quake servers, an 8-port gigabit switch, and a surge protector that provides power for up to eight devices.
Additionally, there will be one pi 4 (2gb) for each player, and it will already be connected to the switch and surge protector, and be booting from a USB drive that already contains all of the quake versions on it.
The idea is to set it on a table, and let players connect their own monitor, keyboard, mouse, and headphones. Since all hardware is equal, all players would have the same "experience" and connectivity quality.
The will be an external ethernet port and power outlet that will allow the user to daisy chain additional "tower" units to add players (four at a time, or however many players are supported by the secondary tower).
Just something taking up space in my brain box...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Sheesh, back in the day Quake was pushing my hardware to its limits. Now you're gonna run this on a freakin' Raspberry Pi?
|
|
|
|
|
Heck, I remember when company networks fell like ninepins because of multiplayer Doom ... 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
from what i understand, you can get upwards of 100fps on a pi4 in quake 3. And it'll be running on a gigabit LAN, so player experience should be outstanding compared to 25 years ago, when it first came out.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Good times. 
|
|
|
|
|
|
Somehow I missed the Quake experience growing up, but a build that encourages local multiplayer gets a  from me.
|
|
|
|
|
My credit union forced me to change my password but won't let me use a previous password.
I don't know why I get irrationally angry over this - I guess I feel passwords are kind of personal and telling me that I cannot use an old one doesn't improve security at all and seems invasive.
If I write insecure passwords changing guest1 to guest2 isn't an improvement.
If I write secure passwords changing TsfI$)#%(fikea;f to IDJOfe30235 isn't an improvement.
There is more B.S. superstition around password management than I can handle.
One of the most boogered things in all of IT are password management systems.
If you write a password management system and force people to change passwords every 30 days YOU ARE A BAD PERSON IN REAL LIFE.
Because of this I need to take a hostage.
I hope she's cute. 
|
|
|
|
|
Their is a simple solution to your problem.
Please log in for further information.
"SWORDFISH"
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I too particularly despise this policy!   
That sure must have been a true password story, somehow!
|
|
|
|
|
Quote: If you write a password management system and force people to change passwords every 30 days YOU ARE A BAD PERSON IN REAL LIFE.
 I completely agree!
|
|
|
|
|
Agree. Ten days should be the absolute maximum 
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
MadGerbil wrote: If you write a password management system and force people to change passwords every 30 days
this is because if your password is compromised and I have it, then I have only 30 days to use it, before I can't anymore. Not so great for you and the company during those 30 days, but it is better than nothing, I guess.
It is a valid level of security. You should be more than glad they don't make you change your password every week.
And no, they are not bad people for doing this. No more as bad as the doctor who tells you to quit smoking.
I agree it is frustrating, very much so.
|
|
|
|
|
The only way my password can be compromised is by mind-reading... Or I give it away...
So the site (that obviously does not store it ) has no reason to be so hard on me...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
Slacker007 wrote: this is because if your password is compromised and I have it, then I have only 30 days to use it, before I can't anymore. Not so great for you and the company during those 30 days, but it is better than nothing, I guess.
What the experts say: Time for Password Expiration to Die | SANS Security Awareness[^]
|
|
|
|
|
The problem with systems that force people to regularly change passwords is that people have a habit of simply incrementing a number at the end of a password.
So the chances are that if I know your password, I can just try incrementing the number at the end until I get your current password which has probably just been incremented by one.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
