InterruptAttach communication area

[gopyan]

Hello friends. I have small question about InterruptAttach func.

This slice from official documentation

int InterruptAttach( int intr, const struct sigevent * (* handler)(void *, int), const void * area, int size, unsigned flags );

area
A pointer to a communications area in your process that the handler can assume is never paged out, or NULL if you don't want a communications area.

More precisely question about area argument. What is the benefit from use of this argument???? But i can use global variables.

I read from documentation - communications area in your process that the handler can assume is never paged out .

Never paged out????????????

IMHO, in RTOS Qnx memory never paged out to hard disk, or I wrong?????

Ok, work with global variables in interrupt handler more slowly than work via area argument. But never paged out confuse me.


Please, friends, shed some light on this delicate point??????

[mario]

More precisely question about area argument. What is the benefit from use of this argument???? But i can use global variables.

Sure you can, but some people don`t like global variables. It`s also nice when you do C++ and you want to pass the this pointer and make the interrupt handler a static method of a class.

I read from documentation - communications area in your process that the handler can assume is never paged out .

Never paged out????????????

IMHO, in RTOS Qnx memory never paged out to hard disk, or I wrong?????

You are right, but during the 6.3.2 period there was provision made to support paging to disk (mostly for desktop usage), but that never really came reality. That being said QSS may decide to bring this feature back alive. So the documentation is warning you.

[maschoen]

Mario,

I recall early in the life of QNX 6, there was a paging feature. It must have been 6.0 or 6.1. The reason for it was simply that the GNU compiler was so big that it didn't fit easily in the memory of machines of that era. It had to be turned on for a specific program to use it, though I don't remember how. Time went on, memory got cheap, the need went away.

I wonder if this is the feature you speak of. Although I don't think that this communications area provision would make sense, as you never would enable paging in a driver.

[sieudot]

Hi all,

Can I wait two interrupts simultaneously (ex: SERIAL PORT and TIMER )?
I want to write an application that has two tasks: the first is receiving data from Serial port (with interrupt IRQ 4) and the second is showing data to the monitor repeatly (with timer clock timeout).

I can do well with timer, but I can not do with serial interrupt. Can someone give me some example source code to do the first task? I have written myself but failed and failed..

[maschoen]

You could wait for those two interrupts by attaching to the interrupt, but that would be a foolish way to do things. The right way would be to wait for serial input by opening the serial device.
The right way to wait for some time period is to use a posix timer.

However if you are just asking about how to do this academically, well you could wait for the two interrupts in two separate threads. I said could. If these two operations have nothing to do with each other, you could do this is separate progams/processes. If they do have something to do with each other, you could still do this in separate programs and have them communicate using messages passing, either directly or through a third process.

[Thunderblade]

The POSIX timer has a downside on QNX though - its accuracy is based on the clock tick! And that's usually only 1 ms. QNX for some reason doesn't support the usage of HPET (High Precision Event Timers). All timing is based on the clock tick. You could lower the clock tick, of course, but that will mean the kernel is triggered more often and your system might become slower.