Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-process support #23

Closed
rokups opened this issue Dec 19, 2018 · 2 comments
Closed

Multi-process support #23

rokups opened this issue Dec 19, 2018 · 2 comments

Comments

@rokups
Copy link
Contributor

rokups commented Dec 19, 2018

My application spawns several worker sub-processes of itself. These instances need plugins loaded as well. Situation here gets hairy. Each subprocess insists on renaming original plugin file and each subprocess is counting from 0. Collisions happen between subprocesses and between subprocess and main process.

Would it be possible to somehow handle this situation?

Few things come to my mind:

Include host process id in renamed plugin name. This is probably not a good idea due to name becoming too long and interfering with patching pdb path on windows.

Create a directory with host process id in it's name, put renamed plugins there. This is probably better, common directory prefix could allow easy cleanup of these directories.

But i do not particularly like either suggestion. Maybe someone has a better idea?

@rokups
Copy link
Contributor Author

rokups commented Dec 20, 2018

Update:
I experimented a bit and concluded that including process id in renamed plugin file name is a viable approach. Test implementation here. For MSVC i also trimmed down PDB path leaving only file name. Debugging still works and this should give a room to breathe for PDB file names. The only situation where it would still break is if someone decided to compile their software in a directory with very short path (like C:\).

@fungos
Copy link
Owner

fungos commented Dec 20, 2018

The most clean would probably to ask for a workspace folder where to put temporary data, this would be per context. But I think the process id is a acceptable and transparent solution anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants