On Feb 9, 7:34 am, Tim Wintle wrote:
> Thanks for both replies,
>
> On Mon, 2009-02-09 at 15:59 +0100, Christian Heimes wrote:
> > You shouldn't use the thread module directly. It's not meant to be used
> > by a user. Please stick to the threading module. You won't notice a
> > slowdown, trust me
On Mon, 2009-02-09 at 21:02 +0100, Christian Heimes wrote:
> The module was renamed to _thread to stop people from using it directly.
> The extension module is the interface to some low level types and
> functions. Especially the usage of thread.start_new_thread is
> problematic, since it bypasses
Tim Wintle schrieb:
> Thanks for both replies,
>
> On Mon, 2009-02-09 at 15:59 +0100, Christian Heimes wrote:
>> You shouldn't use the thread module directly. It's not meant to be used
>> by a user. Please stick to the threading module. You won't notice a
>> slowdown, trust me :)
> I'm aware that
On Mon, 09 Feb 2009 15:34:02 +, Tim Wintle
wrote:
Thanks for both replies,
On Mon, 2009-02-09 at 15:59 +0100, Christian Heimes wrote:
You shouldn't use the thread module directly. It's not meant to be used
by a user. Please stick to the threading module. You won't notice a
slowdown, trust
Thanks for both replies,
On Mon, 2009-02-09 at 15:59 +0100, Christian Heimes wrote:
> You shouldn't use the thread module directly. It's not meant to be used
> by a user. Please stick to the threading module. You won't notice a
> slowdown, trust me :)
I'm aware that thread is being renamed to _thr
Tim Wintle schrieb:
> Hi,
> This is my first post here - google hasn't helped much but sorry if this
> has been asked before.
>
> I've been wondering about some of the technicalities of locks in python
> (2.4 and 2.5 mainly).
>
> I'm using the "old" thread module as (1) I prefer the methods and
On Feb 9, 2:47 pm, Tim Wintle wrote:
> Hi,
> This is my first post here - google hasn't helped much but sorry if this
> has been asked before.
>
> I've been wondering about some of the technicalities of locks in python
> (2.4 and 2.5 mainly).
>
> I'm using the "old" thread module as (1) I prefer t
On 2006-08-04 04:22:59, Ritesh Raj Sarraf wrote:
> Gerhard Fiedler wrote:
>> Rather than downloading and zipping in the same thread, you could run
>> multiple threads like you're doing that only download files, and one
>> zip-it-all-up thread. After downloading a file, the download threads
>> plac
Ritesh Raj Sarraf wrote:
> Bryan Olson on Saturday 05 Aug 2006 23:56 wrote:
>
> > You don't want "ziplock = threading.Lock()" in the body of
> > the function. It creates a new and different lock on every
> > execution. Your threads are all acquiring different locks.
> > To coordinate your threads,
Bryan Olson on Saturday 05 Aug 2006 23:56 wrote:
> You don't want "ziplock = threading.Lock()" in the body of
> the function. It creates a new and different lock on every
> execution. Your threads are all acquiring different locks.
> To coordinate your threads, they need to be using the same
> loc
Ritesh Raj Sarraf wrote:
[...]
> I noticed that even though while one thread acquires the lock, the other
> threads
> don't respect the lock. In fact they just go ahead and execute the statements
> within the lock acquire statement. With this behavior, I'm ending up having a
> partially corrupted
Bryan Olson on Saturday 05 Aug 2006 13:31 wrote:
>> Exactly. Only one thread can hold a lock at a time.
>
> In the code above, a form called a "critical section", we might
> think of a thread as holding the lock when it is between the
> acquire() and release(). But that's not really how Python's
Carl Banks wrote:
> Ritesh Raj Sarraf wrote:
>> Carl Banks wrote:
>>> Then change the zipping part of download_from_web to acquire and
>>> release this lock; do zipfile operations only between them.
>>>
>>> ziplock.acquire()
>>> try:
>>> do_all_zipfile_stuff_here()
>>> finally:
>>> ziplock.
Carl Banks wrote:
>
> Exactly. Only one thread can hold a lock at a time. If a thread tries
> to acquire a lock that some other thread has, it'll wait until the
> other thread releases it. You need locks to do this stuff because most
> things (such as zipfile objects) don't wait for other threa
Ritesh Raj Sarraf wrote:
> Carl Banks wrote:
> > Then change the zipping part of download_from_web to acquire and
> > release this lock; do zipfile operations only between them.
> >
> > ziplock.acquire()
> > try:
> > do_all_zipfile_stuff_here()
> > finally:
> > ziplock.release()
>
> I hope
Carl Banks wrote:
> If you have multiple threads trying to access the same ZIP file at the
> same time, whether or not they use the same ZipFile object, you'll have
> trouble. You'd have to change download_from_web to protect against
> simultaneous use. A simple lock should suffice. Create the
Gerhard Fiedler wrote:
> Rather than downloading and zipping in the same thread, you could run
> multiple threads like you're doing that only download files, and one
> zip-it-all-up thread. After downloading a file, the download threads place
> a message in a queue that indicates the file they hav
On 2006-08-03 08:49:45, Ritesh Raj Sarraf wrote:
> I implemented it but am seeing some issues.
> If I use a single thread, all files are zipped to the archive.
> Obviously this has to work.
>
> If threads are 2 or 3 or 4 in numbers, some of the files don't show up
> in the archive.
>
> What woul
Ritesh Raj Sarraf wrote:
> Simon Forman wrote:
> > > One other question I had,
> > > If my user passes the --zip option, download_from_web() internally (when
> > > the
> > > download is successful) zips the downloaded data to a zip file. Since in
> > > case
> > > of threading there'll be multiple
Simon Forman wrote:
>
> The other threads will just take the next request from the Queue and
> process it. They won't "care" what the one thread is doing,
> downloading, zipping, whatever.
>
As I mentioned in my previous post, the other threads will also have to
go through the same "zip the file
Simon Forman wrote:
> > One other question I had,
> > If my user passes the --zip option, download_from_web() internally (when the
> > download is successful) zips the downloaded data to a zip file. Since in
> > case
> > of threading there'll be multiple threads, and say if one of the thread
> >
Ritesh Raj Sarraf wrote:
> Hi,
>
> I have this following situation:
>
> #INFO: Thread Support
> # Will require more design thoughts
> from Queue import Queue
> from threading import Thread, currentThread
>
> NUMTHREADS = variables.options.num_of_threads
>
>
Hi,
I have this following situation:
#INFO: Thread Support
# Will require more design thoughts
from Queue import Queue
from threading import Thread, currentThread
NUMTHREADS = variables.options.num_of_threads
def run(request, respo
Ritesh Raj Sarraf wrote:
> I'd like to put my understanding over here and would be happy if people can
> correct me at places.
ok :-)
> So here it goes:
> Firstly the code initializes the number of threads. Then it moves on to
> initializing requestQueue() and responseQueue().
> Then it moves on t
Simon Forman on Thursday 27 Jul 2006 22:47 wrote:
> def run(request, response, func=dummy_func):
> '''
> Get items from the request Queue, process them
> with func(), put the results along with the
> Thread's name into the response Queue.
>
> Stop running once an item is None.
> '''
> name = curr
And people, Is there any documentation on Python Threads or Threads in general.
It'd be of great help to really understand.
Ritesh
Ritesh Raj Sarraf on Thursday 27 Jul 2006 16:37 wrote:
> Is this the correct way of threading applications ?
> This is the first time I'd be doing threading. So was
Duncan Booth on Thursday 27 Jul 2006 17:17 wrote:
> What you want is to use a pool of threads so that you can configure how
> many requests are issued at a time (you don't want to try to issue 100
> requests all in parallel). You can communicate with the threads through a
> Queue.
>
Thanks to bot
Duncan Booth wrote:
> Simon Forman wrote:
>
> > If you need help understanding it please ask questions. I, for one,
> > would be happy to comment it for you to explain how it works. It's so
> > nice and elegant that I've already cut-and-pasted it into my own
> > "notebook" of cool useful python "
Ritesh Raj Sarraf wrote:
[snip]
> for item in list_items:
> download_from_web(item)
>
> This way, one items is downloaded at a time.
>
> I'm planning to implement threads in my application so that multiple
> items can be downloaded concurrently. I want the thread option to be
> user-defined.
[s
Simon Forman wrote:
> If you need help understanding it please ask questions. I, for one,
> would be happy to comment it for you to explain how it works. It's so
> nice and elegant that I've already cut-and-pasted it into my own
> "notebook" of cool useful python "patterns" to use in the future.
Ritesh Raj Sarraf wrote:
> Duncan,
>
> I couldn't make out much from the code.
> Instead this is what I did.
>
> threads = []
> nloops = range(len(lRawData))
> for i in nloops:
> (sUrl, sFile, download_size, checksum) =
> stripper(lRawData[i])
> t = thread
Ritesh Raj Sarraf wrote:
> Duncan,
>
> I couldn't make out much from the code.
Please, try again to understand Duncan's code. It's much better than
what you did.
> Instead this is what I did.
>
> threads = []
> nloops = range(len(lRawData))
> for i in nloops:
> (sUrl,
Duncan,
I couldn't make out much from the code.
Instead this is what I did.
threads = []
nloops = range(len(lRawData))
for i in nloops:
(sUrl, sFile, download_size, checksum) =
stripper(lRawData[i])
t = threading.Thread(target=download_from_web, args=(sUrl,
Ritesh Raj Sarraf wrote:
> I'm planning to implement threads in my application so that multiple
> items can be downloaded concurrently. I want the thread option to be
> user-defined.
>
> Looking at the documentation of threads (Core Python Programming), I've
> noticed that all threads are execute
Just napisał(a):
> I always felt that subclassing Thread is very unpythonic. It seems like
> an unfortunate leftover Javaism (much of threading.py was inspired by
> Java, but I don't need to tell you that). If I need some state, I create
> my own class, with a reference to the Thread object if
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Aahz)
wrote:
> In article <[EMAIL PROTECTED]>,
> Kent Johnson <[EMAIL PROTECTED]> wrote:
> >D wrote:
> >>
> >> My question is, how would I go
> >> about creating the thread? I have seen examples that used classes, and
> >> other examples that j
In article <[EMAIL PROTECTED]>,
Kent Johnson <[EMAIL PROTECTED]> wrote:
>D wrote:
>>
>> My question is, how would I go
>> about creating the thread? I have seen examples that used classes, and
>> other examples that just called one thread start command - when should
>> you use one over another?
>
Guys - I appreciate the clarification. So it looks like they used a
class for the ping thread because they were a) running multiple
instances of the thread concurrently and b) needing to keep track of
the state of each instance, correct? I believe that in my case, since
I will be just running on
D wrote:
> My question is, how would I go
> about creating the thread? I have seen examples that used classes, and
> other examples that just called one thread start command - when should
> you use one over another?
For simple use it doesn't matter. Use a class when you want to add more
state or
On 2006-02-28, Felipe Almeida Lessa <[EMAIL PROTECTED]> wrote:
> # He meant calling direct vs. subclassing. In your example you called
> the Thread class directly, but you could have subclassed it.
Yup. I should have realized that.
> # In your case, Edwards, I'd prefer subclassing because the
Em Ter, 2006-02-28 às 20:38 +, Grant Edwards escreveu:
> On 2006-02-28, D <[EMAIL PROTECTED]> wrote:
>
> > Thanks, Grant. I apologize for not being clear on what I
> > meant by using "classes". This is an example of what I was
> > referring to:
> > http://www.wellho.net/solutions/python-pyth
On 2006-02-28, D <[EMAIL PROTECTED]> wrote:
> Thanks, Grant. I apologize for not being clear on what I
> meant by using "classes". This is an example of what I was
> referring to:
> http://www.wellho.net/solutions/python-python-threads-a-first-example.html
Ah, I see. I had forgotten that peopl
Thanks, Grant. I apologize for not being clear on what I meant by
using "classes". This is an example of what I was referring to:
http://www.wellho.net/solutions/python-python-threads-a-first-example.html
See the second (threaded) example.
Doug
--
http://mail.python.org/mailman/listinfo/pyt
Em Ter, 2006-02-28 às 20:24 +, Grant Edwards escreveu:
> > I have seen examples that used classes, and other examples
> > that just called one thread start command - when should you
> > use one over another?
>
> I'm not sure what you mean by "use classes" vs. "calling a
> thread start command"
On 2006-02-28, D <[EMAIL PROTECTED]> wrote:
> I have a client application that I want (behind the scenes) to check
> and make sure a remote host is up (i.e. by ping or TCP connect). I'm
> assuming that, since I want this to go on "unknowingly" to the user,
> that I would put this in a thread.
Pr
45 matches
Mail list logo
