[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch] ped_device_from_store

From: Andrew Clausen
Subject: Re: [patch] ped_device_from_store
Date: Thu, 16 Aug 2001 21:22:07 +1000
User-agent: Mutt/1.2.5i

On Wed, Aug 15, 2001 at 11:11:38PM +0200, Neal H Walfield wrote:
> > > This patch adds a new function, ped_device_from_store, to libparted.
> > > This is useful only on GNU/Hurd and where an application would like to
> > > use libparted.  The function has the following prototype:
> > > 
> > >   PedDevice *ped_device_from_store (struct store *source,
> > >                                     int consume)
> > 
> > The "convention" is for constructors:
> > 
> >     namespace_object_new[_special_way_of_creating]()
> If this is documented some where, could you point me to the location.

I'm doing (99.9%) the same thing as the gtk/gnome people.
I don't know if it's documented, but there are plenty examples.
(That's why I wrote "convention").  Perhaps there should be docs.

Anyway, I'm not flaming you.. just letting you know how I want it ;)
These special constructors are going to be rather common in libparted,
I suspect...

> My rational is that the resource is already open and, as of right now,
> the resource is destoryed when the open_count goes to 0.

Well, this can be changed.

> Since the
> resource is consumable, the other option will destroy it even before it
> leaves ped_device_new_from_store.

Unless you change it.

> > Do you want me to do this?  Or do you have objections...?
> I assume that if you are going to make ped_device_destory available as a
> complement to ped_device_new*, you will also change the behavior of
> ped_device_open/ped_device_close to not destory the resource when the
> open count drops to 0.

They should destroy the resource if they can recover it again later.

> If so, then I fail to see the continued utility
> of ped_device_open/ped_device_close.  Actually, as far as I can tell,
> right now, they really are not open and close meathods, but rather, a
> reference counting system that you use to safely free nonvolatile
> resources (e.g. you can get another file descriptor since you save the
> path to the block device).

Correct.  It allows us to free resources, if they aren't being used
by libparted.  However, we can't free these special resources (and
get them back), so they should only be destroyed on ped_device_destroy().

open_count fundamentally reflects libparted usage, not some OS resource

Feel free to debate the wisdom of this ;)  The motivation is to allow
devices to free up resources if they can.  However, it might be bad to
let users of the API think that open_count == 0 implies that no resources
are being used - but that isn't what it means (in my mind ;)

Maybe users need a guarantee that no resources are being used?
Perhaps: "if you didn't create the device yourself, then it follows
normal semantics?"

Anyway, I like ped_device_close() being equivalent to ped_device_destroy()
is an even worse change (read: violation) of semantics.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]