[Q] inter_process communication in CamlTk,OCaml

[Q] inter_process communication in CamlTk,OCaml

[Bomshik Kim]

Hello.

Now I'm making some application with CamlTk and OCaml.
Problem is how to communicate between GUI part and Working part.

In GUI part, there are start_work button, and stop_work button.
The work is started in a new_process (by fork) by clicking 
start_work button. But the work may take a long time 
(let's assume 10 min) and raise an exception. 
and I want to make the result of work shown on GUI Text.
So GUI part should receive the result from Work part.

Usually, socket is used for inter_process communication.
If recvfrom function is used for receiving the result 
from Work part by UDP, then any other input event is not
archieved. Because GUI waits the result(sleep until receiving the result).
That means user can't stop the work by clicking stop_work button
in the middle of Work processing .

If there is nice method to communicate between parent(GUI part) process
and child (Working part) process, let me know it.

Sincerely

--
Bomshik Kim, M.S. Candidate   
Programming Language Lab.
Division of CS, Dept. of EECS, KAIST
http://ropas.kaist.ac.kr/~bskim

Re: [Q] inter_process communication in CamlTk,OCaml

[Jacques Garrigue]

From: Bomshik Kim <bskim@ropas.kaist.ac.kr>

> Now I'm making some application with CamlTk and OCaml.
> Problem is how to communicate between GUI part and Working part.
> 
> In GUI part, there are start_work button, and stop_work button.
> The work is started in a new_process (by fork) by clicking 
> start_work button. But the work may take a long time 
> (let's assume 10 min) and raise an exception. 
> and I want to make the result of work shown on GUI Text.
> So GUI part should receive the result from Work part.

You might consider using threads. The idea is that you have a main
thread running the Tk main loop, and worker threads started by it.
They may communicate through mutex or events.

CamlTk is not thread safe, so you must be careful about not using any
Tk command in your worker threads, since they may cause race
conditions. Also, this will not work with bytecode threads (the
default) since you won't be able to switch threads once inside the
main loop. You have to compile Caml with posix threads instead.

I'm no expert in thread programming, so I'm not sure whether what I'm
doing is really safe, but this is actually the way the ocamlbrowser
subshell works under windows, using a worker thread to read from a
pipe (file labltk/browser/shell.ml).

Jacques
---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>