Holy cow, I wrote a book!
(co-hosted by former Seattleite Bill Radke—we miss you, Bill!)
a story on the Princeton Laptop Orchestra,
which calls itself
It's an interesting experiment,
but computer music doesn't really move me.
It's not the computer-ness that bugs me
(I was fascinated by music played on Gameboys, after all)
but rather the lack of traditional musicality.
the chord that opens the piece on online gambling creeps me out.
Not because of the piece itself,
but because it is dangerously reminiscent of the chord played
at the Tulalip Casino,
a steady synthesized triad played at low volume so you can
barely hear it.
And after a while, you simply stop hearing it,
and then you have to whack yourself on the head and make yourself
hear it again because allowing it to sink into your subconscious
means that they've won.
Whenever there is a coordination problem,
somebody says, "Hey, let's create a process."
Now you have two coordination problems.
I see this over and over,
and paradoxically the people who create a process for
managing a coordinating problem come off looking like
proactive problem-solvers who get ahead of the problem.
They're the go-getters, the people who look at each problem
as an opportunity for continuous improvement.
All that great management buzzword stuff.
It doesn't matter whether or not the process actually works,
because failure is an orphan,
and besides, nobody follows up a year later to see whether
your process actually improved things or whether it was abandoned six
weeks after roll-out.
You get the credit for proposing the process in the first place.
Consider this problem at a hypothetical toy company:
Some rumors have started that one of their toy cars is dangerous
because of a wiring flaw that can result in excessive heat
and possible fire.
(It doesn't matter what the crisis is.
I just made up something vaguely plausible.)
Employees all over the company are getting email from their relatives
asking about the toys,
but the employees don't know what the story is either.
Presumably, the safety department is investigating the problem
and providing guidance to the PR and marketing departments
so they can prepare a public response, and if there really is
a problem, they're working with the product recall team to organize
how the recall will be carried out,
and they're working with the product engineering team to figure out
what changes need to be made to the product to avoid the problem.
In other words, the safety department is up to their ears in crisis.
A employee from the dolls department, whose brother asked him
about this toy car problem,
can't find any information on the status of this issue and
sends email to the "Employee Issues" alias, and a dozen people
chime in with "Yes, please, we would like this information,
I want to know what I can tell my brother and everybody
else who is asking me about it.
I might even post it on my blog so I can try to counteract
some of the out-of-control rumors that are out there."
A half hour later, somebody from the safety department responds,
"Yes, we know about this, we're working on it.
Please don't say anything publicly since we're still investigating."
Somebody watching the saga unfold
proposes a process by which employees can be kept up to date
on the status of these types of emergent crises.
This is the wrong solution to the problem.
The reason why this is the wrong solution is that
it suffers from the classic "Create work for somebody else" problem.
The people who benefit from this site are not the same people
who would make the site useful.
This doesn't give the people who make the site useful much incentive to do so.
They're busy dealing with the emergency.
They don't want to waste the time of
one of their valuable investigators to do "internal PR".
This scenario repeats itself on a less dramatic scale with
various types of inter-group coordination problems.
One group wants to be kept advised of the progress of another group
for whatever reason.
But if the second group doesn't need the first group for anything,
they have no incentive to keep the first group informed.
For example, suppose the first team provides an interface that
the second team uses,
and the first team decides that they need to redesign the interface
for whatever reason.
During the transition,
the first team provides both interfaces so that the second team
can transition from the old to the new,
with the request that the second team let them know when they
have finished transitioning to the new interface so they can
remove support for the old one.
Unless the first team keeps on top of things,
the second team will probably forget to tell the first team
when they have completed the transition,
or they may even forget to transition to the new interface at all!
After all, the old interface still works.
In this case, the traditional way of making the second team care
is to file a bug against them saying, "Stop using the old interface."
That way, it shows up in their bug statistics as a reminder,
and when they actually do the work, they can resolve the bug
back to the first team.
But you can imagine a scenario where the information the first team
wants is more of a continuous nature rather than a single event.
(Since bugs track single events.)
It's the season where people with fruit trees in their yard
are drowning in fresh fruit, be they pears, apples, plums, whatever.
It's not long before you find yourself desperately looking for
people to give it away to, having pretty much run out of things
you can make plums into.
This is where
Community Fruit Tree Harvest steps in.
The Seattle Times
The Seattle Post-Intelligencer.
Lettuce Link for donating produce from your home garden.)
The volunteers at Community Fruit Tree Harvest will visit your house
and pick the fruit from your tree,
donating it to local food banks.
Everybody wins: You don't have to deal with all the extra fruit,
the food banks get fresh fruit,
nothing goes to waste.
(This is one of those "Why didn't somebody think of this sooner?"
type of programs.)
Contact telephone numbers are on the web pages.
It appears that they currently cover the Wallingford,
Phinney Ridge, and Green Lake neighborhoods.
Let me get this out of the way up front:
Creating a thread from DllMain is
The discussion here has to do with explaining the behavior you
may observe if you violate this advice.
Commenter Pete points out that "according to Usenet"
creating a thread in DllMain is supposed to deadlock,
but that's not what he saw.
All he saw was that the thread entry procedure was not called.
I'm going to set aside what "according to Usenet" means.
Recall how a thread starts up.
When you call CreateThread, a kernel thread object
is created and scheduled.
Once the thread gets a chance to run,
the kernel calls all the
DllMain functions with the
Once that's done, the thread's entry point is called.
The issue with deadlocks is that all DllMain
functions are serialized.
At most one DllMain can be running at a time.
Suppose a DllMain function is running and it creates
As we noted above, a kernel thread object is created and scheduled,
and the first thing the thread does is notify all the DLLs
Since DllMain functions are serialized,
the attempt to send out the DLL_THREAD_ATTACH notifications
must wait until the current DllMain function returns.
That's why you observe that the new thread's entry point doesn't
get called until after you return from DllMain.
The new thread hasn't even made it that far;
it's still working on the
On the other hand, there is no actual deadlock here.
The new thread will get itself off the ground once everybody else
has finished doing their DllMain work.
So what is this deadlock that Usenet talks about?
If you've been following along, you should spot it easily enough.
If your DllMain function creates a thread
and then waits for the thread to do something
(e.g., waits for the thread to signal an event that says
that it has finished initializing,
then you've created a deadlock.
The DLL_PROCESS_ATTACH notification handler inside
DllMain is waiting for the new thread to run,
but the new thread can't run until the DllMain
function returns so that it can send a new DLL_THREAD_ATTACH
This deadlock is much more commonly seen in
where a DLL wants to shut down its worker threads and wait for them
to clean up before it unloads itself.
You can't wait for a thread inside DLL_PROCESS_DETACH
because that thread needs to send out the DLL_THREAD_DETACH
notifications before it exits, which it can't do until your
DLL_PROCESS_DETACH handler returns.
(It is for this thread cleanup case that the function
FreeLibraryAndExitThread was created.)
Undeterred by his
failure to win a Senate seat last year,
Mike Goodspaceguy Nelson once again
ran for King County Council.
I can't bring myself to listen to
his appearance on the local public radio station
(fortunately, he wasn't running in my district).
read his and opponent Dow Constantine's candidate statements
on the King County Elections Web site.
I stumbled across a candidate questionnaire that the
Historic Seattle Preservation Foundation
submitted to all of the candidates for King County City Council,
Michael Goodspaceguy Nelson's response
the response from mainstream candidates Dow Constantine
I have to say that Nelson comes off looking pretty good.
He answers each question honestly, assigning medium or even low priority
to the historic society's hot-button issues, describing how they fit
into his overall plan.
By comparison, Constantine and Hague
pander to the foundation by rating
everything as high priority.
The sole "medium priority" was their assessment of how the council as a whole
prioritized an issue.
"See? I pander to you better than the rest of the council!"
(Note: This message was pre-recorded.
The race was no contest;
Constantine won easily.)
In other local election news,
the race for
another seat on the King County council has been suffering a series of
The incumbent Jane Hague
was arrested for drunk driving back in June,
and the news was kept quiet
until just days before the election,
at which point local politics were thrown into a tizzy.
But wait, there's more.
You'd think the opposition party would be ecstatic,
but they were too busy dealing with their own problems to care,
for the opposition candidate was
perennial also-ran Richard Pope.
("Some people go to baseball games or go fishing.
Richard files for office.")
How did a fringe candidate become the opposition candidate?
State law permits candidates to claim whatever party affiliation they wish,
without needing permission from the party itself,
and Pope has taken advantage of this, changing parties three times during
read the story for details.)
So now we have a choice in November
between an accused drunk and a fringe candidate.
It's going to be a weird election.
One of my many favorite Dilbert cartoons is also one of the
the first strip reprinted in this article.
It may not actually have happened, but I was told that
that one project many years ago replaced its lead manager.
While noteworthy, this sort of thing happens often enough that
people take it in stride.
What put it into a higher category, however,
was that the email that announced this change at the top
was sent while the outgoing manager was out of the country
One can imagine the now-former manager's surprise upon returning
to the office.
"Dum di dum, catching up on email, hey what the..."
Now, the outgoing manager may very well have known
about this change before
heading out on vacation,
but the story is funnier (and I therefore like to believe)
that it was a surprise.