Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: Multiuser database

From: SunandaDH:aol at: 22-Mar-2006 16:15

> A good solution that hasn't been mentioned so far is to use a TCP > listen port as the lock. Two processes are (or at least should > not) never allowed to listen to the same port.
That's true on a single machine. But I think (if I read it right) the original poster wanted to lock a resource on an application that is running (in effect) asynchronously across a number of machines. Gabriele:
> It probably should, but it's likely to be a pain to do in a > multiplatform way (i.e. if we want the exact same behavior in all > platforms)... not that I have studied the issue deeply, though.
I strongly suspect you are right -- the surface commonality would hide a series of opsys-specific locking/semaphoring mechanisms; and then REBOL may be reduced to implementing only the most common features. I can see why it isn't at the top of Carl's to do list. On the other hand, Ada had a rendezvous mechanism (so, in effect semaphores) and async built into the language from day 1. So it must be possible if you have enough Government money. Gabriele:
> The best solution is always to have a single-threaded process > providing serialized access to the given resource. When you can't > do that, you are forced to deal with troubles.
Absolutely. Let me describe a slightly OT example I had to design a couple of years back. It's a humungous legacy application now sprawled across multiple mainframes with hunks chopped off and running on various PC-class machines. And all of a sudden we needed to lock a resource at the application level. Providing a mainframe-wide lock was trivial -- ENQ and DEQ (enqueue and dequeue) have been doing that since before Neal Armstrong bounced around on the moon. A PC-network-wide lock as almost as simple as the PC-side applications used a common SQL database: so we just added a lock table in a simpler manner than the lock files described in earlier posts in this thread. Then some things come for free: like an uncommitted read lets you "peek" at the lock setting without blocking yourself. But combining those two make a single application-wide lock that was foolproof and resilient (so if one side died the other side wasn't blocked) -- well, that was fun. Sunanda.