HP Visualize J5000 hp workstations - hp-ux 10.20 graphics administration guide - Page 116

SIGALRM Details, Other Threads-Related Information

Get HP Visualize J5000 - Workstation PDF manuals and user guides View all HP Visualize J5000 manuals
Add to My Manuals
Save this manual to your list of manuals

Page 116 highlights

Other Threads-Related Information 1. All of the 3D graphics functions are cancellation points. 2. None of the 3D graphics functions are async-cancel safe. 3. None of the 3D graphics functions are async-signal safe. 4. None of the 3D graphics functions are fork-safe, i.e., they cannot be called by a child process after a fork(2), but before an exec(2). Note: Calls to 3D graphics functions between a fork and an exec have never been supported 5. There is one situation in which graphics behavior may be different for multi-threaded versus single-threaded programs. In a multi-threaded Starbase application, a call to gopen(3g) a serial plotter might not return if the plotter does not respond (e.g., if the plotter is turned off). In this multi-threaded case, the graphics thread could wait forever for the device. Singlethreaded behavior in this case is for the gopen(3g) to timeout and return an error. SIGALRM Details The Starbase library temporarily sets a SIGALRM signal handler and uses setitimer(2) to start a timer in two situations: 1. To set a timeout for device access in calls to gopen(3g) for a serial plotter. 2. To set a maximum time to wait for an event in calls to await_event(3g), read_choice_event(3g), read_locator_event(3g), and intread_locator_event(3g). Calls to the above Starbase functions should not be made in one thread while at the same time another thread performs any of the following: • Changes the SIGALRM signal action; • Calls sigwait(2), selecting the SIGALRM signal; • Uses setitimer(2); • Uses timer_settime(2) to set a timer which will generate a SIGALRM signal. Possible consequences of violating these non-concurrency restrictions are: • The Starbase function call never returns; • The wait for a plotter response or for an event is shorter than it should be; • Alarm signals from timers set in other threads do not have the desired effect (because the graphics signal handler is in place); • Unpredictable results due to concurrent use of the process-wide timer provided by setitimer(2). Page 116 Graphics Administration Guide for HP-UX 10.20

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
Other Threads-Related Information
1.
All of the 3D graphics functions are cancellation points.
2.
None of the 3D graphics functions are async-cancel safe.
3.
None of the 3D graphics functions are async-signal safe.
4.
None of the 3D graphics functions are fork-safe, i.e., they cannot be called by a child process
after a
fork(2)
, but before an
exec(2)
.
___________________________________________________________________________
Note:
Calls to 3D graphics functions between a fork and an exec have never been supported.
___________________________________________________________________________
5.
There is one situation in which graphics behavior may be different for multi-threaded versus
single-threaded programs. In a multi-threaded Starbase application, a call to gopen(3g) a
serial plotter might not return if the plotter does not respond (e.g., if the plotter is turned off).
In this multi-threaded case, the graphics thread could wait forever for the device. Single-
threaded behavior in this case is for the gopen(3g) to timeout and return an error.
SIGALRM Details
The Starbase library temporarily sets a
SIGALRM
signal handler and uses
setitimer(2)
to start a timer in
two situations:
1.
To set a timeout for device access in calls to
gopen(3g)
for a serial plotter.
2.
To set a maximum time to wait for an event in calls to
await_event(3g),
read_choice_event(3g), read_locator_event(3g)
, and
intread_locator_event(3g)
.
Calls to the above Starbase functions should not be made in one thread while at the same
time another thread performs any of the following:
•
Changes the
SIGALRM
signal action;
•
Calls
sigwait(2)
, selecting the
SIGALRM
signal;
•
Uses
setitimer(2)
;
•
Uses
timer_settime(2)
to set a timer which will generate a SIGALRM signal.
Possible consequences of violating these non-concurrency restrictions are:
•
The Starbase function call never returns;
•
The wait for a plotter response or for an event is shorter than it should be;
•
Alarm signals from timers set in other threads do not have the desired effect (because
the graphics signal handler is in place);
•
Unpredictable results due to concurrent use of the process-wide timer provided by
setitimer(2)
.
Graphics Administration Guide for HP-UX 10.20
Page 116