Public SourceMage Discussion List

[Dufflebunk <dufflebunk AT dufflebunk.homeip.net>]

Some bugs and fixes were made. One bug that cause simultaneous casts to
fail and also no more deluge of debugging information. No other problems
have popped up, this should be pretty safe. Here is a URL to the latest:
http://dufflebunk.homeip.net/~dufflebunk/sorcerer/liblock


On Mon, 2003-08-11 at 17:21, Dufflebunk wrote:
> Well, due to the drop in discussion, I figured I'd toss some stuff out
> on sm-discuss for discussion. I've redone liblock, it no longer uses
> lockexec. That is good, in that the only reason there was a spell was so
> the program could be used for liblock, but bad because the reason it was
> used was so that it wasn't necessary to sleep for long random periods. 
> 
> The new liblock is much faster at serial locking: lock a, unlock a, lock
> a unlock, ...
> But slower if two processes are trying to lock the same file. The first
> one will get the lock, but the second will sleep up to 5 seconds after
> the lock has been released.
> For serial uncontested locks, I clocked it at about 90 lock-unlocks /
> second. I'm not sure what the old liblock was... somewhere closer to 5 I
> think.
> 
> I've attached the new liblock. It's not in devel sorcery yet. It won't
> go in until I can properly run devel sorcery (that's when devel works
> with test grimoire again). However, that's no reason other people can't
> test it. Do backup your local setting in /etc/sorcery, and stuff in
> /var/state/sorcery. People have tested this so it shouldn't cause Bad
> Things. If you do want to try it out, just replace liblock (it's a drop
> in replacement), and let me know if there are any issues that come up.
> 
> And just to stir things up I'll also mention this, Andrew has written a
> thin wrapper around the sysv message passing stuff for me and I've
> written an interface lib in bash for it. The makes it possible to write
> bash script that pass messages efficiently. I would like to add this to
> sorcery. It would enable us to remove the nasty hacks in there, like
> using files in /tmp for inter-process notices
> (/tmp/casting.*.some-spell.download.success for example). I clocked it
> at 600 ping-pongs / second. It would make the asynchronus stuff much
> nicer to work with. It would be a very nice thing to have, however, it
> requires that the sysv kernel stuff be compiled in and of course the
> binary wrapper. Are those reasonable requirements? Does anyone not have
> sysv stuff compiled in?