Re: interrupts, events, windows, etc...

Sebastian Sardina wrote:
> 
> I am trying to figure out what is the best way to handle asynchronous
> events with ECLIPSE.
> 
> So far I have the following system in ECLIPSE that has 2 independent
> processes under Linux:
> 
> * ECLIPSE program A: does a lot of things, and is connected with program
> B
> via socket. I redefined the input/output interrupt to handle any message
> coming from B. When B sends something, A handles the message and then
> continues with its job
> 
> * ECLIPSE program B: is just a simple program that can send at any time
> a message to program A
> 
> Everything works perfect in Linux, but:
> 
> (a) presumably, one should not use interrupts unless it is really
> necessary right?

Right.


> 
> (b) I cannot use the system under Windows because I cannot modify the
> input-output interrupt handler.
> 
> So I wonder if there is any way I can avoid interrupts and use events
> instead. The problem is that BOTH programs are in ECLIPSE Prolog so
> program B cannot simply trigger an event on process A (as one would do
> from a C/C++ program using ec_post_event() function).
> 
> Is there any way of triggering an event on A whenever B sends some data
> via the socket? Maybe it is inevitable to put some C/C++ code between A
> and B so that such code would use ec_post_event() to throw an event in
> A.

The only way that is portable between Unix and Windows is to
poll the socket(s) using select/3. If you have a pure server
process, it would run a server loop like this:

server_loop(ClientSockets) :-
	select(ClientSockets, block, SocketsWithData),
	( foreach(SocketWithData, SocketsWithData) do
		read(SocketWithData, RequestFromClient),
		handle_request(RequestFromClient)
	),
	server_loop(ClientSockets).


In the setup you describe, you don't have a pure server: your
"program A" does some kind of "idle job" in addition to serving
the requests. It would probably be the best to redesign this
such that you have a pure server and can use a server loop.

If you want to keep the setup you have (and if response time is
not so critical), you could set up a timed event (using
event_after_every/2) which interrupts the "idle job" regularly,
and the event handler could call select/3 (nonblocking) in order
to check whether anything has arrived on the client sockets.


-- 
 Joachim Schimpf              /             phone: +44 20 7594 8187
 IC-Parc                     /      mailto:J.Schimpf@imperial.ac.uk
 Imperial College London    /    http://www.icparc.ic.ac.uk/eclipse