Hi,
3) It makes sense to me even I didn't tried it yet. My understanding of
documentation is that 3) is more preferred in Win32 world.
I see important that name of event must be agreed between wireshark and
extcap. E.g. if generic "Wireshark_shutdown" is used, it shutdowns every
extcap including ones called from different wireshark application. I
think it should not work this way.
Name of Event can be new parameter for extcap, but it requires cmd line
change.
We can try to derive name of Event from filename/pipe to which extcap
writes output. It is different value for every wireshark/extcap
combination. It do not require any changes on command line.
I found no other dependency for use of Events. It looks promising to me.
I don't like this idea because it requires too much effort on the
extcap side to implement just shutdown (the control pipe atleast could
be extended with other uses).
I think so.
On the other hand 2) depends on support on extcap side, but proposed
library solves it.
You assume every extcap developer will happily use the library, but
there are valid reasons not to: license (extcap does not have to be GPL
compatible) and language.
I was not aware of this. Therefore documentation should describe details
for developers.
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.
Best regards,
Jirka
___________________________________________________________________________
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
