ion@svn.reactos.com wrote:
Dispatching & Queue Rewrite II:
- Rewrote wait code. It is now cleaner, more optimized and faster. All waiting functions are now clearly differentiated instead of sharing code.
Imo, sharing the wait code is cleaner... (I remember the time i merged the old wait code into one routine, heh)
These functions
are called up to a dozen times a second, so having dedicated code for each of them is a real boost in speed. - Fixed several queue issues, made a dedicated queue wait/wake function (you are not supposed to use KeWaitFor on a queue,
I used KeWaitXxx in the queue impl. because i thought it was good to have the wait code in one place only. Thou others find speed more important:-D
Gunnar Dalsnes wrote:
ion@svn.reactos.com wrote:
Dispatching & Queue Rewrite II:
- Rewrote wait code. It is now cleaner, more optimized andfaster. All waiting functions are now clearly differentiated instead of sharing code.
Imo, sharing the wait code is cleaner... (I remember the time i merged the old wait code into one routine, heh)
I admit it's cleaner, but speed is more important, imo. Debate that can go on for ages however :)
These functions
are called up to a dozen times a second, so having dedicatedcode for each of them is a real boost in speed. - Fixed several queue issues, made a dedicated queue wait/wake function (you are not supposed to use KeWaitFor on a queue,
I used KeWaitXxx in the queue impl. because i thought it was good to have the wait code in one place only. Thou others find speed more important:-D
This introduces hacks into KeWaitXxx (remember != WrQueue?? :P) and also, if you look inside a checked build of NT, you will find ASSERT(Header->Type != QueueObject) inside KeWaitXxx so that really made me unshare the code :)
Now that these changes are in, I have rewritten thread termination (based on Windows Internals Chapter 11) and thread reaping to use hypercrtical work queues. The code for the latter is much simpler/smaller and also quite faster, since the OS manages everything. Termination also works MUCH better, gets rid of the "terminate type" hacks that were added, and also flushes/delivers all APCs, timers and mutants (we only flushed mutants!). Windows Internals described the process in line-by-line pseudo-code so it was a great help.
I should commit that tonight.
Best regards, Alex Ionescu
Alex Ionescu schrieb:
This introduces hacks into KeWaitXxx (remember != WrQueue?? :P) and also, if you look inside a checked build of NT, you will find ASSERT(Header->Type != QueueObject) inside KeWaitXxx so that really made me unshare the code :)
Can you explain this a little bit more?
- Hartmut
Hartmut Birr wrote:
Alex Ionescu schrieb:
This introduces hacks into KeWaitXxx (remember != WrQueue?? :P) and also, if you look inside a checked build of NT, you will find ASSERT(Header->Type != QueueObject) inside KeWaitXxx so that really made me unshare the code :)
Can you explain this a little bit more?
In order to share the code, Gunnar had to insert a hack into the wait code not to do some things if the wait mode is WrQueue. By using a dedicated function, the hack can be removed.
Best regards, Alex Ionescu
Alex Ionescu schrieb:
Hartmut Birr wrote:
Alex Ionescu schrieb:
This introduces hacks into KeWaitXxx (remember != WrQueue?? :P) and also, if you look inside a checked build of NT, you will find ASSERT(Header->Type != QueueObject) inside KeWaitXxx so that really made me unshare the code :)
Can you explain this a little bit more?
In order to share the code, Gunnar had to insert a hack into the wait code not to do some things if the wait mode is WrQueue. By using a dedicated function, the hack can be removed.
Currently I'm not content with this answer , I expect more an answer to 'if you look inside a checked build of NT'.
- Hartmut
I'm not sure, but i believe he is referring to the 'checked build' versions of windows nt...that is, versions of NT that included debugging symbols.
Hartmut Birr wrote:
Alex Ionescu schrieb:
Hartmut Birr wrote:
Alex Ionescu schrieb:
This introduces hacks into KeWaitXxx (remember != WrQueue?? :P) and also, if you look inside a checked build of NT, you will find ASSERT(Header->Type != QueueObject) inside KeWaitXxx so that really made me unshare the code :)
Can you explain this a little bit more?
In order to share the code, Gunnar had to insert a hack into the wait code not to do some things if the wait mode is WrQueue. By using a dedicated function, the hack can be removed.
Currently I'm not content with this answer , I expect more an answer to 'if you look inside a checked build of NT'.
- Hartmut
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
On Tue, 15 Mar 2005 11:53, Richard Campbell wrote:
I'm not sure, but i believe he is referring to the 'checked build' versions of windows nt...that is, versions of NT that included debugging symbols.
That's the way "Inside Windows NT" uses "checked build".
Hartmut Birr wrote:
Alex Ionescu schrieb:
Hartmut Birr wrote:
Alex Ionescu schrieb:
This introduces hacks into KeWaitXxx (remember != WrQueue?? :P) and also, if you look inside a checked build of NT, you will find ASSERT(Header->Type != QueueObject) inside KeWaitXxx so that really made me unshare the code :)
Can you explain this a little bit more?
In order to share the code, Gunnar had to insert a hack into the wait code not to do some things if the wait mode is WrQueue. By using a dedicated function, the hack can be removed.
Currently I'm not content with this answer , I expect more an answer to 'if you look inside a checked build of NT'.
- Hartmut
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Hartmut Birr schrieb:
Alex Ionescu schrieb:
This introduces hacks into KeWaitXxx (remember != WrQueue?? :P) and also, if you look inside a checked build of NT, you will find ASSERT(Header->Type != QueueObject) inside KeWaitXxx so that really made me unshare the code :)
Can you explain this a little bit more?
Hi,
sometimes I find some pieces of code, with which isn't clearly for me, from where does the knowledge come for the implementation. Such code isn't used and it isn't necessary for the current status of ros. This is only a statement and has nothing to do with the changes from revision 14047. If I see a discussion with an answer which does sound like 'look inside windows and you will find some line of code...', sorry call me paranoid, I must get this clarify. I am a little bit disappointed from the following dialogue. Actually I've expected the following answer or something like this: 'I wrote a test driver and it has hit an assertion on Windows for queues'.
- Hartmut
Hi guys
Due to the nature of the project, ReactOS is a legal minefield. It is easy (and almost required) to point fingers and its also natural to get offended at too much finger pointing. But we need to handle this a lot better.
1) Until someone acts to prove differently, assume everyone is acting in good faith and wants to help 2) Respect that others in the project have the right to query in origins of your code (comes with the 'legal minefield' territory) 3) Separate the 'work' from the 'person' as much as possible during this type of debate; its shouldn't have to get personal!
I realize that a lot of this is my fault; the IP paper is not yet published - I'll rectify this shortly. When there are grey areas we need to decide how we're going to act and publish this in the IP paper.
We can't expect more proof from some committers than others; we must decide on the guidelines for all developers and judge everyone according to the same standard.
Regards Jason
Jason Filby wrote: [snip]
I realize that a lot of this is my fault; the IP paper is not yet published
"IP"? Please don't muddy the waters even more by spreading FUD - even if unintentionally, and even if due to ignorance (else it's lies). If it's about copyright, wite copyright. If it's about patents, write patents. If it's about Internet Protocol...
/Mike
Ermm....IP = intellectual property...
Mike Nordell wrote:
Jason Filby wrote: [snip]
I realize that a lot of this is my fault; the IP paper is not yet published
"IP"? Please don't muddy the waters even more by spreading FUD - even if unintentionally, and even if due to ignorance (else it's lies). If it's about copyright, wite copyright. If it's about patents, write patents. If it's about Internet Protocol...
/Mike
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Alex Ionescu wrote:
Richard Campbell wrote:
Ermm....IP = intellectual property...
I think that was another one of Mike's sarcastic jokes that nobody ever gets ;)
But I got it...
the thing is, IP is a term best reserved for use by lawyers, since it is newspeak. There is no such thing as Intellectual Property.
It's applying property rights to something that is not property, but information.
Information is regulated by copyrights and patents, not property laws.
I can steal your car but I can't steal you patent. I can violate your patent though.
regards, Jakob
(Plus it's a whole different discussion about quality of patents...)
Alex Ionescu wrote:
Richard Campbell wrote:
Ermm....IP = intellectual property...
I think that was another one of Mike's sarcastic jokes that nobody ever gets ;)
The only sarcasm was displaying the established use of IP for "Internet Protocol". The rest was dead serious. If someone uses that (american-lawyer-"invented"?) acronym to bunch together completely unrelated (and NOT universally accepted, nether bunched together nor by themselves) concepts, ideas, conventions and laws, instead of referring to the exact concept they are intending, they are doing this out of two possible reasons:
1. Ignorance. Perhaps the person using the acronym isn't aware these are a number of completely unrelated concepts bunched together? Perhaps it is, but isn't aware that by using the acronym it's hurting others (by using the acronym it gives the acronym credibility)? Perhaps it isn't a person, but a sheep doing what "all others" (within visual range) do? The possibilities are almost endless - but the result is still hurting others.
2. Malice, to (try to) spread the venom to make people believe there is some such universally accepted umbrella term in the real world, where all the concepts they try to cram under this umbrella most certainly are separate, and completely unrelated issues.
Giving the ones using that acronym the benefit of a dubt, I believe most uses are due to ignorance.
But whatever the reasons people use that acronym, it still is spreading of FUD - and it is hurting others (too).
/Mike
Hartmut Birr wrote:
Hi,
sometimes I find some pieces of code, with which isn't clearly for me, from where does the knowledge come for the implementation. Such code isn't used and it isn't necessary for the current status of ros. This is only a statement and has nothing to do with the changes from revision 14047. If I see a discussion with an answer which does sound like 'look inside windows and you will find some line of code...', sorry call me paranoid, I must get this clarify. I am a little bit disappointed from the following dialogue. Actually I've expected the following answer or something like this: 'I wrote a test driver and it has hit an assertion on Windows for queues'.
- Hartmut
Hi Hartmut,
Sorry for lashing out against you -- I've had an extremly bad week, if that's any excuse --. I've been sick, tired, unadmitted to my first choice university, and spent sleepness nights with the branch patching.
Both Gunnar and I knew about the beaviour of Queues && KeWaitXxx, my reply with him was an "inside joke" on the reason why I un-shared the code. Since he argued that speed is not imporant for him, but it is for me (our usual chat conversion ;), I brought up as an "inside joke", "Hey, btw, windows also asserts!". This was not the reason for the changes, and is just a joke I was playing on Gunnar. I understand that due to its nature it might've raisen some flags with you, and I probabaly overeacted. I don't mean this in an offending way, but your English sounded as if you were attacking me (or it might've been that bad week I've been having).
In any case, that assert had nothing to do with the changes and it comes out of a publically viewable information inside XP Checked Build.
Best regards, Alex Ionescu