Since my only experience of STM is through Clojure and threads I don't even know if a similar locking mechanism can be implemented in PicoLisp since here we have forked processes instead.
As usual my knowledge of Unix/Linux internals is too lacking to say anything definite, despite having recently started reading The Art of Unix Programming. This section seems to imply though that it would be possible to implement STM between forked processes http://www.catb.org/~esr/writings/taoup/html/ch07s02.html#id2922148 (the shared memory section) or? Or maybe it already exists somehow implicit in PicoLisp? On Thu, Sep 15, 2011 at 3:14 PM, Alexander Burger <a...@software-lab.de>wrote: > Hi Henrik, > > > The fact that Clojure enforces this way of working is seen as one of it's > > greatest virtues and strengths. If PicoLisp's boss works in the same way > you > > have the same situation where you don't have to worry about inconsistent > > data. > > In PicoLisp you usually don't have to worry about inconsistent data. > > The threads ('task's) are strictly cooperative (not preemptive), and > database modifications by separate processes are synchronized > automatically. > > However, I would not stress (or mention) 'boss' here. Typically, IPC > between PicoLisp processes, and DB modifications, are coordinated > between sister processes by the same parent (the "boss") in an implicit > way. Talking to "boss" directly, and forcing it to do things, I regard > as quite dangerous, because the parent should be loaded as little as > possible and - more important - should not execute any application- > level code. The parent should never be allowed to crash, as this would > cut IPC between the children and give undefined results. > > Instead, sister processes send messages to each other via 'tell' > (broadcasted, or to selected processes), and synchronize DB operations > via 'put!>' (or 'dbSync', 'put>' and 'commit' sequences), which also use > 'tell' internally. 'tell' has a well-defined behavior, as it is > dispatched centrally by the parent, and the resulting events in the > children's tasks are non-preemptive again. > > > > (pipe (boss 'addToFoo 2)) > > > > (pipe (boss 'multiplyFooWith 3)) > > Using pipe in that way to create a short-term child process is an > interesting idea. I would rather have done it the obvious way: > > (unless (fork) > (boss 'addToFoo 2) > (bye) ) > > But why not? 'pipe' should work here, and it is shorter. The drawback is > some system call overhead. > > Cheers, > - Alex > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
