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. [1] https://github.com/robertmillan/rumposs/blob/master/open.c#L38 -- Robert Millan
