[linrad] Re: Error exit (and multi-platform)

[<leif@xxxxxxxxxx>]

Hi Frank,

> > Ok, what about threads waiting for keyboard, mouse events,
> > network input or other I/O functions?
> > I have set the parameters for CANCEL_ASYNCHRONOUS and
> > put start and stop of hardware drivers in the main routine.
> > Do you see any problem with that?
> 
> I'd need a little more detail before answering with 
> certainty, but in general it should be fine. CANCEL_DEFERRED 
> is probably what you want in order to achieve termination at 
> neat and convenient points.
The thing is that the expected event might never happen
because the error condition might be within the device driver. 
(or the mouse/keyboard is not touched.) I need the thread to 
become killed anyway.
 
> > What about threads that do not exit explicitly, the ones
> > killed by pthread_cancel() from the thread having the thread
> > killing as its single task?
> > It it safe to join only the thread that has killed all the others?
> > There are many different modes of operation with different threads 
> > running and it would be nice to not have to keep track of everything
> > under error exit conditions;-)
> 
> That should be OK too. A typical thing to do would be to 
> maintain an array of thread IDs. The killing thread would
> simply loop through the array, cancel each of them in turn, 
> (except itself, of course) and then do a join on the one 
> just cancelled. Or it could do a cancellation loop and then 
> a join loop. The order isn't particularly important with 
> CANCEL_DEFERRED. It would then simply exit to a join in the 
> main routine.
OK. I understand this to be fine under normal conditions
but under error conditions some threads might not reach any 
suitable point - that is why they are CANCEL_ASYNCHRONOUS.

Normal thread exit is by a return to a join from where the
thread is created because each thread loop is a 
{
while(flag)
  {
  code
  }
return;
}
 
> > Ctrl C is doing something, is it impossible to do the same from
> > within an arbitrary thread within the program?
> 
> Yes. You need to trap the Ctrl-C by having a signal handler 
> thread catching SIGINT. Man sigblock. It's a little 
> complicated but really only needs to be worked out once :-) 
> The protocol is slightly more complicated than for 
> traditional signal handlers since you need to localize which 
> thread receives the signal. Also, signals trapped with 
> sigblock are "reliable" in the sense that they are never 
> dropped in a race condition, unlike traditional signals.
??????
I do not want to trap ctrl-C. I would like to send a ctrl-C
as if the keyboard were pressed. I have noticed that the ctrl-C
always(?) gives a clean exit.

> > What happens if I join threads that have already been killed?
> > (In case it is unsafe to join only the "kill everything" thread?
> > The code is intended to be portable to MS Windows and
> > Macintosch...
> 
> A join on an inactive thread merely returns immediately. No 
> danger.
Oooh! Fine. Then I can just joine all threads while
writing the thread identities on screen. In case
one is alive, the program will hang on the join
and I will see what the problem is - and then I get
out with ctrl-C. This solves everything (I think)


> The arrangement, except for the SIGINT signal handler, 
> should be the same in any environment that supports 
> pthreads. The port to Mac OSX should be immediate.
> 
> One of the advantages of using a gui environment like QT or
> gtk is that all of these details are hidden behind the 
> environment-specific event queuing and delivery mechanisms.
OK. I noticed there were arguments in favour of QT before.
I did look at it but was unable to figure out how to use it.
I am not a programmer in any way - my focus is on radio
and signal processing algorithms....

What about porting to other platforms? Not using QT means
that everything platform specific has to be explicitly written
within the Linrad package. These are the functions needed:

1) Configure the screen. It has to be set to 256 colours and
at least 640x480 pixels. The Linrad 256 colour palette
has to be loaded and a font has to be selected and initiated.

2) Configure the mouse so there will be a system call
that a thread can hang on waiting for events.

3) Configure the soundcards so suitable device drivers
and parameters will be associated to the four functions. 
RX_AD (1 to 4 channels, 16 or 32 bit, 6kHz to 192kHz or more)
RX_DA (1 to 2 channels, 8 or 16 bit, 5kHz to 24 kHz)
TX_AD (1 channel, 8 or 16 bit, 6 to 24 kHz)
TX_DA (1 or 2 channels, 8 or 16 bit, 6 to 192kHz or more)
The actual open statement should then be platform independent.

4) A function set_pixel(x,y,colour) Set a pixel on the screen.

5) A function write_string(x,y,string) Put the selected string
of fonts starting at the selected position on screen.

6) A function set_text_colour(colour) Set the colour with which
fonts will be written when write_character(x,y,char) is called.

7) A function to grab an area from the screen and store the
bit map in user space.

8) A function to place a bit map from user space on screen.

Linrad also uses svgalib functions to draw lines and rectangles
but if the above can be arranged it should be trivial.

I intend to structure Linrad with the platform specific
routines in one or a few files. Besides the main.c which
will check whether the screen is set up and do the setup
dialog there will only be the the above platform specific
calls (hopefully)

Do you or anyone else see any problems with the above 
strategy?

Can I compile a .EXE file for Windows 2000 with GCC under
Linux? What about Mackintosch?

73

Leif / SM5BSZ



#############################################################
This message is sent to you because you are subscribed to
  the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>

LINRADDARNIL