Re: IOLockSleepDeadline example in docu is wrong (won't compile)
Re: IOLockSleepDeadline example in docu is wrong (won't compile)
- Subject: Re: IOLockSleepDeadline example in docu is wrong (won't compile)
- From: Markus Hanauska <email@hidden>
- Date: Wed, 5 Sep 2007 10:34:05 +0200
Okay, but in that case, could Apple please update their webpage to
represent the code in a way that compiles. Many people tried to tell
me, that this depends on the system version, however, I checked for
10.2, 10.3 and 10.4 and it's always the same, at least to the SDKs
found in my Xcode installation.
I tried the memcpy solution, and it worked just fine, though it's a
lot of code to do a small thing, sleeping for a couple of ms. So as
someone suggested, I'm now using IOSleep instead, which seems to do
exactly what I want to do (why would I want to do IODelay? Where is
the advantage of wasting plenty of CPU time for a couple of ms - a
spin lock is maybe meaningful if you sleep for a couple of ns or us,
because there the sleep/wake-up would take longer than the actual
time to sleep, but if you sleep more than one ms, I guess it's fine
to real put the thread to sleep).
Basically this sleep is only performed if the kext is unloaded and
honestly, how often does that happen on a system? It's basically
something only developers need (real users usually don't manually
unload kexts) - so any performance hit that IOSleep may produce is
acceptable.
On 2007-09-05, at 01:06, Terry Lambert wrote:
On Sep 4, 2007, at 5:22 AM, Markus Hanauska wrote:
I can't cast a number to a struct. Publishing source code that is
supposed to not even compile is not only silly and confusing
programmers, it's outreight useless.
Seeing that the struct is endian safe, I assume I can do the
following:
AbsoluteTime deadlineTime;
memcpy(&deadlineTime, deadline, sizeof(deadline));
correct?
You can do that, or you can explicitly coerce the type at the call
site (you can cast the address of a struct to a number pointer, and
dereferernce it if you are calling the one function, or explicitly
reference it if you're not.
This is basically a wart from the passing of the address of the hi
and lo values into a number of functions in user space case, which
means we could not convert it to a 64 bit type without changing the
symbol decoration used by C++, which would have introduced binary
compatibility issues.
A Google for the following keywords will find you a bunch of examples:
compile errors for AbsoluteTime
-- Terry
--
Best Regards,
Markus Hanauska
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden