int main()
{
alarm(2);
printf("still going\n");
while (1);
printf("should this line be executed?\n");
}
I understand that alarm() will interrupt the execution, set the alarm to go off and hand it back. Why does the last line not get executed?
It's not printed because while(1); is an infinite loop. So, in the absence of the alarm() call, that would run forever.
However, the signal generated two seconds after you call alarm() will cause the program to terminate if you're not catching it.
What it won't do is cause just the loop to exit and the program to carry on. It will shut the program down, quick smart.
If you do catch the signal but your catching function just returns, it will end up back inside the infinite loop.
For more detail on those two cases, examine the following code:
#include <stdio.h>
#include <unistd.h>
#include <signal.h>
int fired = 0;
void handler (int sig) {
fired = 1;
}
int main (void) {
// signal (SIGALRM, handler);
alarm (2);
printf ("Starting.\n");
while (1) {
if (fired) {
fired = 0;
printf ("Alarm fired.\n");
alarm (2);
}
}
printf ("You will never see this.\n");
return 0;
}
If you run that code, it will print out the Starting message, run for about two seconds, then exit without printing anything else. That's because you're not catching the signal so the default action is to just terminate the process.
If you uncomment the call to signal() (disregard for now that it's considered preferable to use sigaction() instead), you'll see the Starting message, followed by a Alarm fired message about every two seconds.
That's because you are catching the signal but, on exit, it returns to inside the infinite loop.
while (1);
This is an infinite loop. Execution will never go beyond this.
Related
I am running a script in CAPL where I am supposed to notice a change in the value of a signal (for example: signal B) coming from the ECU. At the start of the timer, I change the value of another signal (for example: signal A) and sent it to ECU over CAN Bus. While the timer is running, I want to see the changed value of signal B coming from ECU as a response to the changed value of signal A. After the timer has run out, I want to reset the signal A back to its original value.
*Note: I have called the different signals as Signal A and Signal B only for understanding the question more clearly
Signal A changes the value from 2 to 0.
Signal B has original value of 61, and the changed value can be any number between 0-60.
Timer runs for 4 seconds.
I am using while loop and command (isTimerActive(timer)==1), to check for the change in the value of signal B when the timer is running.
Below is the attached Code ->
variables
{
msTimer Execute;
}
on key 'c'
{
setTimer(Execute,4000);
Write("Test starts");
SetSignal(Signal A, 2);
while (isTimerActive(Execute)==1)
{
if ($Signal B != 61)
{
Write("Test pass");
}
else
{
Write("Test fail");
}
}
}
on timer Execute
{
write("Test over");
setSignal(Signal A, 0);
}
I am executing this code and the value of signal A changes to 2 but
there's no change in the value of signal B. I am using the
(isTimerActive (timer) ==1) in the while loop, is it the correct command
for my problem?
Also, when I run (isTimerActive (timer) ==1), CANoe becomes inactive and
I have to stop CANoe using Task manager.
Any ideas how can I correct my code and get the desired response?
Thanks and Best
CAPL is event-driven. Your only choice is to react on events by programming event handlers, i.e. the functions starting with on ....
During execution of an event handler, the system basically blocks everything until the event handler has finished.
Literally nothing else happens, no sysvars change, no signals change, no timers expire, no bus messages are handled, and so on.
For test-modules and -units the story is a little bit different. There you have the possibility to wait during execution of your code using the various testWaitFor... methods.
With your current implementation of on key ‘c‘you basically block the system, since you have an while loop there waiting for an Timer to expire.
As stated above, this blocks everything and you have to kill CANoe.
Fortunately changes of signals are also events that can be handled.
Something like this should do:
Remove the while block and instead add another event handler like this:
on signal SignalB
{
if(isTimerActive(Execute))
{
if ($SignalB != 61)
{
Write("Test pass");
}
else
{
Write("Test fail");
}
}
}
The code is called when SignalB changes. It then checks whether the Timer is still running and checks the value of the signal.
Instead of $SignalB inside of the handler you can also write this.
In an event handler this is always the object that has caused the event.
What I'm trying to do is fairly simple. Transmit through DMA and wait till it gets transmitted. And then receive and wait till it is received.
When I comment out the receive part(including the call back), it is going into the transmit complete call back function. But when I un-comment the receive portion, it is not going into the tx cplt call back and it is directly going into the receive cplt callback. And when I check the receive buffer I'm not getting what I expected(obviously). What could have gone wrong?
I'm using Atollic True Studio V 9.0 , CubeMx v5.1.0, STM32F407VG-DISC1 board and enabled DMA for UART2.
I've tried sending char buffer through UART DMA and receive it. It seems it is not transmitting at all as it is not going into txCplt call back. And it is directly going into Rxcplt call back.
uint8_t tx_arr[10], rx_arr[10];
__IO ITStatus UartReady = RESET;
int main(void)
{
int i = 0;
for(i = 0; i<10; i++)
rx_arr[i] = 0;
for(i = 0; i<10; i++)
tx_arr[i] = i*2;
HAL_Init();
SystemClock_Config();
MX_GPIO_Init();
MX_DMA_Init();
MX_USART6_UART_Init();
MX_USART2_UART_Init();
while (1)
{
if( HAL_UART_Transmit_DMA(&huart2, (uint8_t*)tx_arr, 10)!= HAL_OK )
{
Error_Handler();
}
while(UartReady != SET)
{
}
UartReady = RESET;
if( HAL_UART_Receive_DMA(&huart2, (uint8_t*)rx_arr, 10)!= HAL_OK )
{
Error_Handler();
}
while(UartReady != SET)
{
}
UartReady = RESET;
}
}
void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart)
{
UartReady = SET;
}
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
{
UartReady = SET;
}
I expect the rx_arr will get filled by 0,2,4,6,...18 but it is getting filled with junk
As this looks to me, the reason is that you are using the same flag variable from both ISRs, both times doing busy waiting in your main loop.
If you uncomment both handler actions, you will sooner or later end up with a race condition where both handlers put their "SET" value quickly one by one - before the main loop waits for it. Then, the main loop "consumes" this flag by setting the variable back to "RESET". A few lines later, the other waiting loop comes and isn't served (because both ISRs ran earlier and only left a single "SET" value, one overwriting the other). Then, your main loop is stuck.
In order to verify my assumption, you can activate a one-sided watchdog before entering into the main loop, and trigger it every main loop cycle. If the main loop gets stuck as I assume, you will detect that the reset cause points to the watchdog afterwards.
Suppose I have a libusb program that just uses the hotplug API. You register a callback and then apparently have to call libusb_handle_events() in a loop which then calls your hotplug callback.
int LIBUSB_CALL hotplugCallback(libusb_context* ctx,
libusb_device* device,
libusb_hotplug_event event,
void* user_data)
{
cout << "Device plugged in or unplugged";
}
void main()
{
libusb_init(nullptr);
libusb_hotplug_register_callback(nullptr,
static_cast<libusb_hotplug_event>(LIBUSB_HOTPLUG_EVENT_DEVICE_ARRIVED | LIBUSB_HOTPLUG_EVENT_DEVICE_LEFT),
LIBUSB_HOTPLUG_NO_FLAGS,
LIBUSB_HOTPLUG_MATCH_ANY,
LIBUSB_HOTPLUG_MATCH_ANY,
LIBUSB_HOTPLUG_MATCH_ANY,
&hotplugCallback,
this,
&hotplugCallbackHandle);
for (;;)
{
if (libusb_handle_events_completed(nullptr, nullptr) != LIBUSB_SUCCESS)
return 1;
}
return 0;
}
The question is, without timeout hacks how can I exit this event loop cleanly? I can't find any functions that force libusb_handle_events() (or libusb_handle_events_completed()) to return. In theory they could just never return.
Sorry if this is late.
The question could have been phrased better but I'm assuming (from your comment updates) that your actual program resembles something a little closer to this:
int LIBUSB_CALL hotplugCallback(libusb_context *ctx,
libusb_device *device,
libusb_hotplug_event event,
void *user_data) {
cout << "Device plugged in or unplugged";
}
void SomeClass::someFunction() {
libusb_init(nullptr);
libusb_hotplug_register_callback(nullptr,
static_cast<libusb_hotplug_event>(LIBUSB_HOTPLUG_EVENT_DEVICE_ARRIVED | LIBUSB_HOTPLUG_EVENT_DEVICE_LEFT),
LIBUSB_HOTPLUG_NO_FLAGS,
LIBUSB_HOTPLUG_MATCH_ANY,
LIBUSB_HOTPLUG_MATCH_ANY,
LIBUSB_HOTPLUG_MATCH_ANY,
&hotplugCallback,
this,
&hotplugCallbackHandle);
this->thread = std::thread([this]() {
while (this->handlingEvents) {
int error = libusb_handle_events_completed(context, nullptr);
}
});
}
Let's say your object is being deallocated and, no matter what is happening on the USB bus, you don't care and you want to clean up your thread.
You negate this->handlingEvents and you call thread.join() and the thread hangs for 60 seconds and then execution resumes.
This is done because the default behavior of libusb_handle_events_completed calls libusb_handle_events_timeout_completed and passes in a 60 second timeout interval with plans to make it infinite.
The way you force libusb_handle_events_completed to return is you call libusb_hotplug_deregister_callback which wakes up libusb_handle_events(), causing the function to return.
There is more info about this behavior in the docs.
So your destructor (or wherever you want to stop listening immediately) for the class could look something like this:
SomeClass::~SomeClass() {
this->handlingEvents = false;
libusb_hotplug_deregister_callback(context, hotplugCallbackHandle);
if (this->thread.joinable()) this->thread.join();
libusb_exit(this->context);
}
In the function:
int libusb_handle_events_completed(libusb_context* ctx, int* completed)
You can change the value of the completed to "1" so the function will return without blocking
According to their docs:
If the parameter completed is not NULL then after obtaining the event
handling lock this function will return immediately if the integer
pointed to is not 0. This allows for race free waiting for the
completion of a specific transfer.
There is no functions in libusb that force libusb_handle_events() to return.
It's recommended to use libusb_handle_events() in a dedicated thread so your main thread will not be blocked by this call. Even though, if you need to manipulate the call of the event handler you can put the call in a while(condition) and change the condition state in your main thread.
Libusb documentation details this here.
I have never get this before; i'm doing a simple program: a father process which creates child processes, and after it terminates; this is the code
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
int child(pid_t pid)
{
printf("process %d is terminating\n",pid);
exit(EXIT_SUCCESS);
}
int main()
{
int i;
for(i = 0; i < 2; i++){
if(fork() == 0)
child(getpid());
}
printf("father, pid=%d terminated\n",getpid());
/*if(wait(NULL) == -1)
perror("wait");*/
exit(EXIT_SUCCESS);
}
when i run, all processes printed, but one process, i think father but i'm not sure, doesn't terminate because terminal is active(doesn't appear $);
insted, if i insert commented line with wait, program runs correctly; why this?
terminal output
If you look at the last run in the screen capture, you'll see "process 8429 is terminating" after the terminal prompt has been printed to the screen.
What appears to be happening is your "father" process happens to exit first, and your shell then outputs the prompt. Then, in the last case, the child process (PID 8429) printed its output and then exited.
So it is terminating, but sometimes the child process doesn't terminate until after the parent process exited and your shell process has already printed the prompt.
Just hit "enter" again when it does that, and you should see a proper shell prompt. Or even enter a command, and it should run normally.
I need to block and wake a process using SIGUSR2 and SIGUSR1 respectively. Below here's my signal handler sub routine. How do I wake a process blocked by pause?
void sig_handler(int sig) {
static int i = 1;
if(sig == SIGUSR2) {
pause();
}
else if(sig == SIGUSR1) {
/* I don't what to write here */
}
}
Also, I read somewhere pause() is not a good programming practice, is there any other means to suspend a process for some time?
See this page
In general, doing a lot of works in signals is ... tricky. Some things are not async-signal-safe, and therefore it makes robust programming there a bit difficult. In your case, pause() waits for a signal to arrive, but since you are calling it from the signal handler, it is not going to work there (I think).
As to making the process sleep and resume on signals. Look at the page I linked above. The best way is to have the signal handlers simply set flags and have the main thread (i.e. in main() or in an event loop) react to these flags. As recommended by the page, use sigsuspend when SIGUSR2 is received to pause the process until SIGURS1 is received.
It's simple. Use the 'kill' system call-
void sig_handler(int sig) {
static int i = 1;
if(sig == SIGUSR2) {
pause();
}
else if(sig == SIGUSR1) {
kill(<pid of process to wake up>, sig);
// make sure that process with pid has registered for sig
}
}