https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12845
--- Comment #48 from Guy Harris <g...@alum.mit.edu> ---
(In reply to Roland Knall from comment #47)
> Sadly, it is much worse. I forgot, that I investigated the issue some time
> ago.
>
> On Unix, we use g_spawn_sync, but for Windows that would require an extra
> application, which we do not want to provide. The approach taken here is
> valid
No approach that uses a fixed-size buffer for the standard output or error is
valid unless we can successfully impose such a limit on *all* extcap programs.
> The only solution is to make
> the extcap sync call an async one, and fetch until EOF and handle the limit
> on our side.
UN*X's "reading from multiple sources" model is primarily based on
select()/poll()/etc. loops, with some "asynchronous I/O" capability provided in
newer UN*Xes; Windows's model is primarily based on starting I/O operations
that proceed asynchronously and provide notifications when they complete, with
no real *general* direct equivalent to select()/poll()/etc.. In this thread:
https://news.ycombinator.com/item?id=11865608
one of the commenters (Trent Nelson, "trentnelson") speaks of the UN*X model as
"readiness-oriented" and the Windows model as "completion-oriented". See also
his slides at
https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploited-all-cores?slide=52
So, on Windows, it appears you can't just use pipe handles in
WaitForMultipleObjects() to wait for data to be readable on the pipe, you
probably have to do "overlapped" I/O and, instead, wait for an event object
that's triggered when the I/O completes.
What Trent is discussing is server-side, where the multiple connections on
which you're doing I/O are handling separate clients, and multi-threading is a
win, as you can use multiple processors on Big Honking MP Servers. That's not
as important here, where you're only multiplexing the standard output and error
from an extcap program, and possibly also user input, so the solutions may be
simpler.
--
You are receiving this mail because:
You are watching all bug changes.___________________________________________________________________________
Sent via: Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
