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
