Hi Tomas, > I have attached my updated code which almost works now. The only > problem is that I seem to be loosing messages and the whole thing > comes to a deadlock.
>From a short inspection I could see only one problem so far: (de main (N) (when (fork) (setq *Monitor @) (push '*Bye '(kill *Monitor))) (setq *Philosophers # Build a list of PIDs The main process sets '*Monitor' to the pid of the forked process. But after that, both processes continue with '(setq *Philosophers'. This causes the monitor process also create all those children. Better would be something like (de main (N) (ifn (fork) (wait) (setq *Monitor @) (push '*Bye '(kill *Monitor)) ) (setq *Philosophers # Build a list of PIDs > I am wondering how/when picolisp calls the asynchronous handler? Is This happens in the functions 'wait', 'sync', 'listen' and 'key', or when waiting for user input at the console. > there a way of disabling asynchronous events temporarily for a block > of code? Do you get similar problems with db synchronisation? I haven't observed any ;-) So there is no need to disable the events, as they are not strictly asynchronous, but can only happen when one of the above functions is called. For database synchronization, for example, this is done in 'dbSync' (lib/db.l:750). A transaction on a db that is accessed by more than one process is always surrounded by (dbSync) and (commit 'upd), or done implicitly by the 'put!>' etc. methods of the '+Entity' class. > I imagine that the problem is that 'defer' called from the IPC handler > changes '*Pending' queue while the 'while' loop is evaluated. I don't think so. Deferred expressions only contain 'giveNow', which in turn only calls 'handOver' -> 'changed' -> 'philState'. Nowhere in this chain is a call to one of the above functions. I didn't take the time yet to directly debug or trace it, though. > So this unnamed pipe is works only between two picolisp processes? I > guess I need to use a named pipe if the child is a non-picolisp > program, e.g. http://logand.com/gtk/gtk.l Yes, if that program accepts and handles a named pipe. More typical for communication with external programs are socket and the stdio channels. > Do you have any document/notes describing how is the picolisp db > implemented. Maybe some high-level overview like how the db files are > accessed, the processes synchronized and data read/written? Not yet, but this would be really necessary. BTW, wouldn't be the handling of '*State' a good candidate for the 'state' function? Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe