On 01:14 pm, jren...@gmail.com wrote:
>Sorry, I don't think I understand the example either---looks to me like
>you're reimplementing a semaphore. Stephen's right about run().
It sounds like (the other) Jason would be happy with run, except he also
wants to do something extra each time the lock/
Sorry, I don't think I understand the example either---looks to me like
you're reimplementing a semaphore. Stephen's right about run().
Cheers,
Jason
On Mon, Feb 7, 2011 at 11:37 PM, Jason Heeris wrote:
> On 8 February 2011 12:22, Stephen Thorne wrote:
> > I totally misread your example, and
On 8 February 2011 12:22, Stephen Thorne wrote:
> I totally misread your example, and I appologise. I've read it now and
> it looks fine to me. The only commend I'd make is that you probably want
> DeferredLock not DeferredSempahore if this is serialised access.
No need to apologise, happens to a
On 2011-02-08, Jason Heeris wrote:
> On 8 February 2011 11:46, Stephen Thorne wrote:
> > Um, that's what I mean, you shouldn't be using .acquire() or .release(),
> > just .run(). doSerialStuff doesn't need a reference to the semaphore
> > object.
>
> So... how can I update the property and emit t
On 8 February 2011 11:46, Stephen Thorne wrote:
> Um, that's what I mean, you shouldn't be using .acquire() or .release(),
> just .run(). doSerialStuff doesn't need a reference to the semaphore
> object.
So... how can I update the property and emit the signal upon
acquisition and release? Or are
On 2011-02-08, Jason Heeris wrote:
> On 8 February 2011 10:45, Jason Rennie wrote:
> > I think what you have duplicating functionality---you're not taking
> > advantage of the DeferredSemaphore.
>
> I thought using the "run" method *was* the preferred way to use a DS,
> but whatever works.
> >
>
On 8 February 2011 10:45, Jason Rennie wrote:
> I think what you have duplicating functionality---you're not taking
> advantage of the DeferredSemaphore.
I thought using the "run" method *was* the preferred way to use a DS,
but whatever works.
> You'll want "sem" to be a global---use wherever yo
On 2011-02-07, Jason Rennie wrote:
> d = sem.acquire()
> d.addCallback(doSerialStuffAndRelease)
Shouldn't this be spelled:
d = sem.run(doSerialStuff)
Which does acquasition and release of the sempahore properly?
--
Regards,
Stephen Thorne
Development Engineer
Netbox Blue
_
I think what you have duplicating functionality---you're not taking
advantage of the DeferredSemaphore. Try something like this:
sem = DeferredSemaphore(1)
def doSerialStuffAndRelease(sem):
# ...perform serial port communication...
sem.release()
d = sem.acquire()
d.addCallback(doSerialS
I'm using a DeferredSemaphore with a token count of 1 to control
access to a serial port. I also have a GTK object for which I'd like
the "in-use" property to change (and notify listeners) when the
resource is in use. So far, I have something like this:
class SerialResource(gobject):
# P
10 matches
Mail list logo
