SICKAG / sick_scan_xd

Based on the sick_scan drivers for ROS1, sick_scan_xd merges sick_scan, sick_scan2 and sick_scan_base repositories. The driver supports both Linux (native, ROS1, ROS2) and Windows (native and ROS2).
Apache License 2.0
90 stars 83 forks source link

Fork-Function with strange behaviour #275

Closed cblesing closed 3 months ago

cblesing commented 5 months ago

Hey everyone,

I recently asked in #269 about the best way to control two scanners without ROS. Me and my colleagues decided to use the old c-function fork() to generate two processes. The plan was that each of that processes then runs one scanner. But we encountered a strange behaviour when we use fork. If I link the sick scan xd library in the CMakeList into our program, the fork-function did not work properly. To make it easier to see here is the code, it is very simple :)

{
    int id = fork() 
    printf("Hello from %d\n", id)
    return 0
}

And here is the CMakeList part:

    target_link_libraries_system(mwb
    lib_mqtt
    lib_api_core
    lib_common_config
    sick_scan_xd::sick_scan_xd_shared_lib)

Nothing special here. If we dont use the sick scan xd lib, the output of of the 3 lines of code is of course:

    Hello from 37031 
    Hello from 0

But if we link your library in we get only:

    Hello from 0

What is going on there? It seams that the main/parent process is no longer there. Do you have any idea why or how this happend? I had a look at your top level CMakeList.txt but did not found a hint or so. Thanks in advance.

Best regards, Christian

rostest commented 5 months ago

Thanks for your feedback. I am not sure that the use of fork creates completely independent processes. The man page on https://www.man7.org/linux/man-pages/man2/fork.2.html says: "The entire virtual address space of the parent is replicated in the child, including the states of mutexes, condition variables, and other pthreads objects." I would not rule out the possibility that replicated mutexes are blocking execution. But this is just a guess.

If you are using MQTT, which I think is a good choice, you might implement a MQTT client for each lidar and run them in 2 separate processes.