endaaman
commented
2 years ago Hello @iTakeshi, thanks for the several contribution too.
At now, process isolation is partly implemented. See this condition ( https://github.com/endaaman/tym/blob/master/include/common.h.in#L31-L37 ). The bus name differs between the release and debug version because when we are debugging, if the bus name of the debug version was the same as release version, the debug build would spawn a window on the primary process of the release build tym that we are working on at the time and the process would be integrated to the one process and exit immediately.
In the latest implementation that all instances are united into the one primary process, if it encounters a fatal error such as segmentation fault, they will be all dead. Compared to the past implementation, this would be not nice. But I don't think this is severe because usual GTK apps adopt this way and the fatal error rarely occurs so we don't necessarily need the special care about this.
To avoid "chain-death" like this, I think we have the 2 ways. The first way is to a make a bus name unique, not an object path. Even though the object path is unique, if its bus name is same, the instance will be united to the primary process. A bus name is a kind of symbol that all instances are tym's ones, while an object path is one to identify each instance. To acquire an unique bus name, I also considered about request cascade like you argued. But there are some problems.
- All name requesting must be done asynchronously.
- When the new instance spawns while this cascade is processing, we don't know what would happen.
- To make ID unique, need to communicate with all instances because new instance don't know any IDs.
The second way is just to add G_APPLICATION_NON_UNIQUE flag. It is used so far in the latest release. It should be easier and more appropriate. It has the limitation that the apps don't have unique bus name and can't correctly handle D-Bus method call.
I experimentally added --isolated on the branch isolated https://github.com/endaaman/tym/tree/isolated (
To set the application flags before GApplication is instantiated, the bunch of changes were needed ).
While I appreciate @endaaman's outstanding effort in #75 implementing such a useful IPC functionality, I am concerned that all active tym sessions will be affected (i.e., killed) when a process running on a tym session causes a fatal error like segmentation fault. However, during implementing or testing new systems, we often have to run binaries which may cause such serious problems.
Therefore, I'd like to propose implementing isolated tym processes that can be spawned independently from the primary tym process, on which all the standard tym windows depend. An isolated tym process should be executed like
$ tym --isolated.assigning unique id for an isolated process
Since each tym window has to have a unique D-Bus object path (
/me/endaaman/tymXXX), we have to assign a unique id (XXX) for an isolated process. This should be solved via the following constraints and procedures:65535(or something).65536 + randint(referred to as "CAND")/me/endaaman/tymCAND