[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] [PLEASE TEST]: New locking code
- To: pygame-users@xxxxxxxx
- Subject: Re: [pygame] [PLEASE TEST]: New locking code
- From: "Charlie Nolan" <funnyman3595@xxxxxxxxx>
- Date: Tue, 10 Jun 2008 17:23:55 -0500
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: pygame-users-outgoing@xxxxxxxx
- Delivered-to: pygame-users@xxxxxxxx
- Delivery-date: Tue, 10 Jun 2008 18:24:02 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=vGZ+QjB51zG3jHu8clyCFDiP8pAh+nH1YIK7GGEbIDA=; b=kUdp94j2tdVSqangULO74SGTd+SCQLRg7roaiBTnXaHUDS41fdK/dasfiAxrw0v+59 TCnbYMRs8GqUmNQItoqYA4zeRkwUJTw9Kh3YxJCYL80y0/MZQI6Dki6t8JGBE1wgUJxr fbxg1jvz7fY/5zomRiMs1KMMYzwDa3XJP2sug=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=UWQlzoPDXmWmsm7BgaD0MKkNJld6skXg80dhK6Lvs7Zqump4SBR+kRxN1s3IJNId/r u+N805Ofkwy6dPuereaN/9McHjalJwWsaUYIZr7sDxhPStfCgSgY5mVX31ZkOpZxwt9Z 7O1IlHbeDjdryhXjC9SXopm3HHLP3Ls1SfX5s=
- In-reply-to: <20080610205148.GC1105@xxxxxxxxxxxxxxxxxxx>
- References: <20080610205148.GC1105@xxxxxxxxxxxxxxxxxxx>
- Reply-to: pygame-users@xxxxxxxx
- Sender: owner-pygame-users@xxxxxxxx
Errors should never pass silently.
Unless explicitly silenced.
-FM
On 6/10/08, Marcus von Appen <mva@xxxxxxxxxxxx> wrote:
> Hi,
>
> regarding Jake's unlock() report I changed the locking behaviour to be
> more strict about who can unlock a locked surface.
>
> While it was possible to completely unlock a surface at any time from
> anywhere, it is now strongly tied to the object, which caused the lock.
>
> While it was possible to do stuff like
>
> subsurface = surface.subsurface (...)
> subsurface.lock ()
> surface.unlock ()
> # surface is unlocked again although subsurface is locked
> ...
> sfarray = pygame.surfarray.pixels3d(surface)
> surface.unlock ()
> # Monsters live here
> ...
>
> you now have to explicitly release the lock using the object that caused
> it:
>
> subsurface = surface.subsurface (...)
> subsurface.unlock ()
> surface.unlock () # No effect
> subsurface.unlock () # Now the lock is released.
> # surface is unlocked again
> ...
> sfarray = pygame.surfarray.pixels3d(surface)
> surface.unlock () # Nothing happens
> del sfarray # Surface will be unlocked
> # Rainbowland's coming!
> ...
>
> The surface.get_locked() method was adjusted accordingly and works as
> supposed now. Additionally the surface got a new get_locks() method,
> which returns a tuple with the object holding a lock. Though this is not
> always exact or very helpful, it can give you a quick overview about the
> reason for a dangling lock (numpy surfarrays for example are not listed,
> but a surface buffer instead as that one caused the lock).
>
> As this is tightly bound to reference counts, weakref pointers and other
> big sources for errors, I beg anyone to test it extensively with your
> code.
>
> Attached you'll find the patch, which hopefully brings love, joy,
> happiness and less errors to pygame.
>
> Regards
> Marcus
>