Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!husc6!mailrus!ames!oliveb!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Who's got the lock?
Message-ID: <53381@sun.uucp>
Date: 16 May 88 16:28:18 GMT
References: <8805160340.AA23871@cory.Berkeley.EDU>
Sender: news@sun.uucp
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 17

In article <8805160340.AA23871@cory.Berkeley.EDU> (Matt Dillon) writes:
>	Actually, Locks are quite rigid.  The workbench guarantees that...
>that is, a bug in the workbench guarantees it.  You see, the workbench does
>a very bad thing to locks ... it copies them manually.  So the size of a 
>lock MUST be EXACTLY sizeof(struct FileLock) or you will crash the workbench.

But the workbench is getting moved from ROM->Disk in 1.4 and word at the
Developers Conference was that there were 'significant' improvements in
the works for workbench. So this is probably one of them. I think the key
thing to consider is that the 'architecture' of locks and try not to build
in any dependencies one their internal structure. Thus when they change 
your program won't crash. Note that the only legal way to copy a lock is
with the DupLock() call.

--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.