expectations of context - multiple processes?

[jimthouston]

I did a quick gui to send configuration strings to an xyphro usbgpib adapter.
See: https://github.com/xyphro/UsbGpib
This is a USB adapter to the GPIB bus that was/is used by vintage test equipment.

I found that I could not count on leaving the connection to the device open. I got it to work by opening and closing the device each time I needed to access it.

The initial symptom was a stack trace and a EBUSY error. Here are the interesting bits:

File "/usr/lib/python3.8/multiprocessing/spawn.py", line 116, in spawn_main
...
usb.core.USBError: [Errno 16] Resource busy

I sprinkled in a few print(os.getpid()) calls and found that query that failed was being called from a different process. I was also surprised that there were more calls accessing the hardware than I would have expected.
I suspect that failure is that the new process is reopening the device which is still open in the original process and returns the EBUSY.

I'm not including code because I don't expect you to have the usbgpib hardware. I may experiment to see if the same problem happens with something simple like a serial port.

It has me curious how this works. I wish there was an overview of the nicegui source. I would settle for a pointer to the code that triggers the spawn call above.

[falkoschindler]

@jimthouston In case you're running NiceGUI with ui.run(reload=True, ...) (the default), uvicorn will spawn a new process whenever a file change is detected. Apart from that NiceGUI's run.cpu_bound is using multiprocessing. Out of the top of my head, these are the two ways in which NiceGUI can use multiple processes.