Hello!
You are the guru for
open()/read()/write()/select()/close()/socket()/pipe()/... operations.
Our intention was not to outline all the implementation details for sure.
But it's a problem that you propose something without thinking about all
the consequences your proposal implies. It's not as trivial as it looks
like from your point of view as AES program. There are a lot of side
effects that need to be evaluated too (but if I ask here I just got the
answer this is implementation detail, nothing important).
So the question for you is "Is there any way to get it like this?".
With or without the side effects you don't want to discuss?
discussed before) would be completely normal. The AES would write there
the output in a form of a return value of event_multi() call. The client
would be woken up from select() and would read the value. It would also
call the event_multi_*() to get the rest information it needs.
Btw. where is the big advantage here now against an enhanced evnt_multi
except that you need an additional system call to process AES events?
AES should be able to detect whether the client read from the pipe or not
and if it is not beeing read than it should rewrite the value (I think
this will need some more implementation details, but I think they are not
necessary at this moment).
Yeah, I love such answers.
Regards,
Frank
--
ATARI FALCON 060 // MILAN 060
-----------------------------------------
http://www.cs.uni-magdeburg.de/~fnaumann/
e-Mail: fnaumann@freemint.de