Adding another helper may be helpful, as it would probably gives us greater control, and maybe also solve the "helper-script" issue in the future by putting that stuff inside Wireshark? I am just wondering if it is worth the effort. We can obviously strive for a perfect - no user interaction required - solution, but do we really need to be perfect here?
In my experience, as long as we can solve the real issue - the zombie processes - and have minimal interaction by the creators of the original extcaps we should be fine. Now as I understand it, we can achieve that at some level with one of the proposed solutions above, just not in an ideal way, right? I am fine with having developers adapt their script, as long as there is some form of compatibility mode, and maybe some warning displayed before starting a non-converted extcap kind regards Roland Am Di., 23. Aug. 2022 um 10:38 Uhr schrieb Tomasz Moń <deso...@gmail.com>: > On Mon, Aug 22, 2022 at 9:37 PM Jirka Novak <j.no...@netsystem.cz> wrote: > > >> What do you think about that options? > > > > > > I have no idea why you didn't even consider sending CTRL_BREAK_EVENT > > > using GenerateConsoleCtrlEvent() as a graceful shutdown mechanism on > > > Windows. Wireshark creates all extcaps with a hidden console window > > > (CREATE_NEW_CONSOLE and SW_HIDE flags set). > > > > > > CTRL_BREAK_EVENT is really simple to handle on extcap side, as it only > > > requires calling SetConsoleCtrlHandler() to register a handler. The > > > handler will be called in separate thread (unlike UNIX signals), but > > > the issues related to the separate thread are exactly the same in any > > > of the three methods you proposed. Registering handler is really an > > > opt-in, as the default handler simply terminates the process. > > > > I'm sorry, my understanding was it is in !2063. I was wrong, I will try > it. > > The problem with GenerateConsoleCtrlEvent() is that the caller has to > be attached to the target process console. While we could technically > do so, it requires freeing any already open console because process > can be attached to at most one console. The pretty much only sane > solution to the problem is to have a helper program between Wireshark > and extcap. > > The helper would simply spawn extcap with provided parameters and > accept commands from Wireshark e.g. on pipe. The commands would be to > gracefully terminate (CTRL_C_EVENT or CTRL_BREAK_EVENT) and forcefully > terminate (TerminateProcess()). Note that the helper must not be > forcefully terminated as it would leave the extcap running. > > While far from ideal, I think the helper is the only sensible > approach. Note that GLib gspawn-win32-helper does something different, > so going back to the GLib helper is not what this is all about. > > Best Regards, > Tomasz Moń > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
