On 01/11/15 10:42, Robert Millan wrote:
El 31/10/15 a les 23:56, Antti Kantee ha escrit:
I'd say it's impossible, but I wonder if there are known
elegant alternatives.
Not impossible, but don't think it's "elegant" either, just a matter of dealing
with a bunch of cases:
http://nxr.netbsd.org/xref/src/lib/librumphijack/hijack.c?r=1.119#1983
Thanks. Well I see how it works for the libhijack case, but I'm unsure running
mutiple threads would be an option for me (this is a real-time application,
using a poll()-based event loop for low-latency response).
Have you considered mirroring the Rump fd space into the host? Say, for example,
each time a Rump fd is created, a dummy host fd is created first, and the same
number as the host is used in Rump.
I've done something similar before using /dev/null [1]. If instead of /dev/null
something that can generate poll()-able events is used (a pipe?), Rump core
could use this to notify host poll()ers about the good (or bad?) news that some
work is to be done.
Does this sound completely insane? I was hoping there would be a cleaner
solution that doesn't impact latency the way thread IPC would.
Yes, it does sound completely insane. For instance:
* it cannot be implemented with existing hypercalls
* supporting dup2 or std{in,out,err} fd's is not possible
* avoiding open races in multithreaded programs sounds difficult
* how to keep the ghost descriptors up-to-date? with a thread?
Perhaps you can describe your application and based on that we can
figure out what the best option for your application is.
