[Sussex] AppleScript and Red Hat 8.0

[Geoff Teale]

Morning,

..and still we roll on... let me know when this gets boring ;)

Tony wrote:
-----------
> If a hardware trigger signal causes the premature stacking of another
> process, service of the trigger, then back to the main 
> process then I would
> call this an interrupt. But if the signal is, say, buffered 
> and the main
> process is terminated at a pre-determined time to poll the 
> buffer then this
> is pre-emptive scheduling, not an interrupt - the basis of most large
> time-sharing systems. And if the hardware trigger signal 
> causes a software
> event to be placed in a queue for processing after the 
> natural termination
> of a certain part of the main process (such as 1 iteration 
> through the major
> program loop) then this is event processing (a la Mac) and is not an
> interrupt - although in all 3 cases the effect is (almost) 
> the same - the
> difference being latency.

OK.. we've wandered completely off the original topic here, however this is
an interesting topic so I will discuss it further in the hope that between
us we might actually be writing something that people are interested in
reading :)

To clarify (not to patronise) I have never come across a modern hardware
platform that didn't use Interrupt Requests and didn't suspend a current
process to handle them in some manner.  I know for a fact that PPC based
systems like Apples work by handling IRQs (because my first QNX dev platform
at Thomson was a PowerPC G4). 

I think you've got the general idea of what you are saying right.  However I
would argue strongly that an interrupt does still happen - an interrupt is
what you call a "hardware signal" and that interrupt is still being handled
- it's just that the kernel is handling it in a generic manner (writing to
the message queue).

I think what you've missed is that "Events" don't actually remove the need
to have interrupt handlers at all - they just provide a mechanism whereby a
lot of the workload can be offloaded to a later scheduled timeslot.  To be
explicit, the "Event" is created by the interrupt handler - <emph>there is
always an interrupt</emph>.

In QNX we use two different methods to connect a "handler" function to an
interrupt: InterruptAttach() and InterruptAttachEvent(). The essential
difference between InterruptAttach() and InterruptAttachEvent() is the way
in which the driver is notified that the device has triggered an interrupt.

With InterruptAttach(), the driver's "handler" function is called directly
by the kernel. Since it's running in kernel space, the hander is severely
restricted in what it can do. From within this handler, it isn't safe to
call most of the C library functions. Also, if you spend too much time in
the handler, other processes and interrupt handlers of a lower or equal
priority won't be able to run. Doing too much work in the interrupt handler
can negatively affect the system's realtime responsiveness. In my experience
its advisable to do the bare minimum within the handler and return an event
to be delivered to the driver at process level. Then, the rest of the work
associated with handling the interrupt can be completed at process time and
will be carried out at the driver's normal priority.  Typically, a driver
would simply acknowledge the interrupt at the hardware level within its
interrupt handler and would return an event in order to wake up the driver
thread that will perform the remainder of the processing.

Using InterruptAttachEvent() when the driver triggers an interrupt, will
cause the kernel to automatically deliver an event to the driver without any
further processing at that stage.  This is the mechanism you are describing
on the Mac - crucial to this though is the fact that an Interrupt is still
happening in order to create the "Event" - it is simply being handled by the
kernel without starting another process.  The CPU will still suspend
processing of the current process in order to do this.

However, I have some doubts as to whether this Event Queue is the same one
that AppleScript is talking to.  I would take a guess that the Event's
you're dealing with have already been handled by the drivers and passed back
into the system as some higher level event.  What you're talking about below
certainly indicates a software request for action (pure IPC) rather than
some direct response to a user interaction.

..hope that all makes sense.



> No - applications do not maintain separate message queues - 
> they write to
> the system queue and although they can read from it they 
> would not normally
> do so. An app opens a document by sending an 'open document 
> event' to the
> main system queue - AppleScript would activate the app and 
> then send the
> same event to the queue - it is driving the system, not the 
> app interface.

OK. I see what you're getting at.  You use the script to immitate the
application talking to the OS and then the application itself deals with the
results.  

 
> Ook! Convinced - will install RH8 tomorrow. Now in process of 
> backing up Mac
> to install OS X. If all OK then will have a spare PC (ex-Win 
> Me) to play
> with at home ...

Cool.  I handed Red Hat 8.0 to two complete newbies this week, neither of
whom have had a problem.  I'm not sure it'll do the "Network Neighbourhood"
type mallarchy, although I haven't really looked at that side of things just
yet, but it certainly provides an easy default environment.

-- 
GJT
geoff.teale at claybrook.co.uk




The above information is confidential to the addressee and may be privileged.  Unauthorised access and use is prohibited.
 
Internet communications are not secure and therefore this Company does not accept legal responsibility for the contents of this message.
 
If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
 
Claybrook Computing Limited is a subsidiary of Claybrook Computing (Holdings) Limited
Registered Office: Abbey House. 282 Farnborough Road, Farnborough, Hampshire GU14 7NJ
Registered in England and Wales No 1287205
 
A Hogg Robinson plc company