removeall() in list

[castironpi at gmail.com]

On Jan 12, 8:04 am, castiro... at gmail.com wrote:
> On Jan 11, 5:26 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
>
> > castiro... at gmail.com writes:
>
> > 1. Put a single thread in charge of the list, and communicate with it
> > by message passing through Queues.  To get X out of the list, you'd
> > send the mutator thread a message asking for removal.  The mutator
> > thread would loop reading and processing messages from the queue,
> > blocking when no requests are pending.  This is sort of the preferred
> > Python style and is pretty simple to get correct, but if there are
> > many such objects you can end up with more threads than you really
> > want.
>
> I've heard this called 'fire and forget'.  You can insure that
> mutations are honored one-at-a-time  and in the order received.  How
> do you make a -read- operation; wait for queued mutations, that is
> lock for a turn on the queue?  Can you optionally read whatever the
> state is, regardless of what's happened in the meantime?  Thing is,
> one thread needs its -own- preceding operations completed before a
> reading operation.

Brainstorm.

First, isolation of problem:  Terminates at 2000 or so, on my
computer.

import thread
import time
import random
counter= 0
def simplecounter():
	global counter
	ret= counter
	counter+= 1
	time.sleep( random.uniform( 0, .001 ) )
	return counter
glist= []
def th3():
	while 1:
		ret= simplecounter()
		glist.append( ret )
		print ret,
		assert glist== range( 1, len( glist )+1 )
thread.start_new_thread( th3, () )
time.sleep(1)
thread.start_new_thread( th3, () )
time.sleep( 1000 )

Second, the thoughts:  'with a.callbacklock():' looks best currently.

'''multithreading ideas:
1.  Put a single thread in charge
	a.k.a. fire and forget.
	- Lots of extra threads
	+ But most are blocking most of the time
	+ honored one-at-a-time, and in order received
	+ ...optionally including read-access, blocking on
	to get return values
	a. synchronous callbacks, for read-access
		+ multi-step, user-definitionized operations
		- one consumer can hang an entire object
		i.  with a.callbacklock():?
			+ only call acquire() from curr. thread, enqueue
			lock obj., released from producer thread "soon"
			using message-queue semantics
	b. mini-transaction, guarantees all and only
		consumer's ops occur in succession
		- can't do anything amidst an indivdual locking
		- no multi-step ops
2.  Lock mutation and/or all operations
	a. Locker.op
	b. with Locker.withop
	- In Python, other programmers always have access
	to your data; nothing guarantees they'll use "with locker"
	+ User-definitioning quite easy
3.  @mutation decorator
	def mutation( func ):
		def newfunc( self, *a, **k ):
			self.lock.acquire()
			func( *a, **k )
			self.lock.release()
4.  List-only solution:
	Use a dictionary, map item to its index.
	To retrieve, sort on value, not key
'''