Rixstep
 About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Learning Curve » Developers Workshop

Tuesday Ten

'It'll be good for something.'


Get It

Try It

STOCKHOLM (Rixstep) — Alfred's day falls on Tuesday this year. That's the day of the year in Sweden when things are as much not as they appear as any other day. Or more.

The envelopes given the laureates at Konserthuset are empty. They're supposed to contain millions but they're empty. The money transfers are arranged some other way. What bearing this has on the movie with Paul Newman and Elke Summer, the German girl who plays Paul's Swedish escort in Stockholm, is not known. As with Leo G Carroll, very much a Brit, but here suddenly a Swede.



Things are not as they appear to be in Stockholm on 10 December. On embassy row, the classic joke is:

'Hey, you ever hear of this year's winner for literature?'
'Nope, nothing. You?'
'Nope!'


Likewise with the science prizes, but there were no jokes about that. What usually happens is you'd hear that so-and-so won the prize for medicine or something, for the discovery of blah-blah, and people would wonder 'but what's that good for?' And the pat reply would inevitably be 'we don't know yet but it might turn out to be something big'.

The transistor, for example, won the prize in 1956. No one's going to challenge that today.

In the spirit of Brian Kernighan, and may he be forgiving for the simile, but his attitude towards computing science is important: sometimes you have to research and dig just to find things out, and only later will you see if you've reaped any tangible rewards. It's always about getting eyes on the system. As your knowledge grows, you come upon ways to utilise that knowledge.

What does David Cutler look like? One of us asked the question of one of our colleagues who'd worked with Cutler for years in Redmond.

Like a Marine, came the direct reply.

Was it true he punched holes in the walls at Microsoft?

Yes it was. This guy and his crew went into Seattle to buy an empty picture frame to hang over the hole. Always good for a laugh, and much appreciated by Dave.

Dave was responsible for the architecture of NT. An operating system has to be the brainchild of one person and only one person, he used to say. His NT was based on his earlier system VMS. It wasn't object-oriented, as too many teachers assumed, but object-based. Getting those teachers to understand wasn't always easy.

Dave's system was a file server. It wasn't made for Internet use. Dave had very little inkling about the Internet. And servers were supposed to run unattended in dark vaults behind lock and key.

Everything is synchronised. Dave had dedicated synchronisation objects, but even ordinary objects could be used for synchronisation. Our Windows application CIP became an integral part of our own course in systems programming - it used every object in the book and then some.

One can't in advance know the speed of an Internet connection, so the semaphore value had to be variable. Only so many query threads could be out in the 'ether' at any given time. As the DNS responses came in, new threads could be created. And so forth.

Change Notifications

One of the most interesting, coolest, and most useful of Dave's synchronisation objects was the 'change notification'.

https://docs.microsoft.com/.../nf-fileapi-findfirstchangenotificationa

Basically what you want is a thread in a wait state that rouses only when a change has been made to a given directory. The sample we used to use in class had to do with a scenario where a server would intermittently get stock market updates over the line and then want to propagate that information to a client. The server thread slept until something happened to the directory, indicating that fresh data had arrived.

Key to this scenario is what happens at kernel level. The synchronised thread can't be in queue for execution. It's not known yet if Unix can manage that, but Apple's Spotlight underbody can. What's not known about this underbody is the extent to which 'observers' also sleep and are not allocated any CPU whatsoever.

But the prospect is tantalising. Namely a generic functionality to sleep on changes to a given directory. The Apple code is riddled with relics from the Carbon era, but whatever. The idea is to build a number of working prototypes to begin with, then a number of useful administrative tools as well, so that the techies can select or remove directories to monitor. The reaction code for these toys will of course do no more than report on the notifications, appropriately in a window pane in the interface.

As to what it's all good for? Pretend it's a bit like a science prize. You don't know today, but someday you will. Or, as the Swedes would say, 'det kan vara bra att ha' - 'it'll be good for something'.

About Rixstep

Stockholm/London-based Rixstep are a constellation of programmers and support staff from Radsoft Laboratories who tired of Windows vulnerabilities, Linux driver issues, and cursing x86 hardware all day long. Rixstep have many years of experience behind their efforts, with teaching and consulting credentials from the likes of British Aerospace, General Electric, Lockheed Martin, Lloyds TSB, SAAB Defence Systems, British Broadcasting Corporation, Barclays Bank, IBM, Microsoft, and Sony/Ericsson.

Rixstep and Radsoft products are or have been in use by Sweden's Royal Mail, Sony/Ericsson, the US Department of Defense, the offices of the US Supreme Court, the Government of Western Australia, the German Federal Police, Verizon Wireless, Los Alamos National Laboratory, Microsoft Corporation, the New York Times, Apple Inc, Oxford University, and hundreds of research institutes around the globe. See here.

All Content and Software Copyright © Rixstep. All Rights Reserved.

CONTACT INFO:
John Cattelin
Media Contact
contact@rixstep.com
PURCHASE INFO:
ACP/Xfile licences
User/Family/Business
http://rixstep.com/buy
About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.