By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,767 Members | 1,354 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,767 IT Pros & Developers. It's quick & easy.

New to threads. How do they work?

P: n/a
gel
Hi all
I am attempting to understand threads to use in a network app which I
am writing. The part that I am going to use threads on is run on the
clients/workstations. I will monitor all starting and ending
processes. Below is what I have been doing. It looks like only the
first thread is starting. Can someone explain a basic example of how
threads work and are implemented, what is better to use threading or
thread module, and what am I doing wrong in the example below. I know
I have asked a lot of questions, any help/direction would be
appreciated.

Thanks

import wmi
import pythoncom
import thread

def create():

pythoncom.CoInitialize()
c = wmi.WMI()
while 1 :

print "watching creation"
watcher = c.watch_for(notification_type="Creation",
wmi_class="Win32_Process", delay_secs=1)
print watcher()
def delete():

pythoncom.CoInitialize()
d = wmi.WMI()
while 1 :
print "watching deletion"
watcher = d.watch_for(notification_type="Deletion",
wmi_class="Win32_Process", delay_secs=1)
print watcher()

thread.start_new_thread(create(),())
thread.start_new_thread(delete(),())

Jul 20 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
gel

Dennis Lee Bieber wrote:
On 19 Jul 2006 19:08:12 -0700, "gel" <ge**@tasmail.comdeclaimed the
following in comp.lang.python:
import thread
Step one... Skip the thread module and use threading module instead.
def create():

pythoncom.CoInitialize()
c = wmi.WMI()
while 1 :

print "watching creation"
watcher = c.watch_for(notification_type="Creation",
wmi_class="Win32_Process", delay_secs=1)

I don't know WMI, but is that delay a real sleep operation, or a
polling loop?

And either could be a problem if they hold the GIL -- preventing
anything else from running until they return...

thread.start_new_thread(create(),())
thread.start_new_thread(delete(),())

At the very least, I suggest commenting out the COM and WMI calls --
test threads that ONLY print output and do a time.sleep(1). That should
be sufficient to see if the threads themselves are being started.
--
Wulfraed Dennis Lee Bieber KD6MOG
wl*****@ix.netcom.com wu******@bestiaria.com
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: we******@bestiaria.com)
HTTP://www.bestiaria.com/
Thanks alot for your help. I had tried using threading with a
different setup in the function side but did not get success. I think
that I have winner now. Thanks again. What follows is the what I have
working so far. And another question why do you prefer to us threading
and thread?

import wmi
import pythoncom
import threading

def create():

pythoncom.CoInitialize()
c = wmi.WMI()
while 1 :

print "watching creation"
watcher = c.watch_for(notification_type="Creation",
wmi_class="Win32_Process", delay_secs=1)
print watcher()

def delete():

pythoncom.CoInitialize()
d = wmi.WMI()
while 1 :
print "watching deletion"
watcher = d.watch_for(notification_type="Deletion",
wmi_class="Win32_Process", delay_secs=1)
print watcher()

import threading
threading.Thread(target=create).start()
threading.Thread(target=delete).start()

Cheers

Jul 20 '06 #2

P: n/a
In message <11*********************@s13g2000cwa.googlegroups. com>, gel
wrote:
I am attempting to understand threads to use in a network app which I
am writing.
It is written, somewhere in the philosophy of *nix programming, that threads
are a performance hack, to be avoided wherever possible. Use processes in
preference to threads.
Jul 21 '06 #3

P: n/a
On 2006-07-21, Lawrence D'Oliveiro <ld*@geek-central.gen.new_zealandwrote:
In message <11*********************@s13g2000cwa.googlegroups. com>, gel
wrote:
>I am attempting to understand threads to use in a network app which I
am writing.

It is written, somewhere in the philosophy of *nix programming, that threads
are a performance hack, to be avoided wherever possible. Use processes in
preference to threads.
I've never understood the aversion people seem to have to
threads. Especially in Python they seem very straightforward
to use and easy to understand. I find IPC between processes is
much more work to do and difficult to get right.

Maybe it's just because threads are what I'm used to, since
I've been using them for 20+ years -- most of the platforms for
which I write don't have "processes".

--
Grant Edwards grante Yow! INSIDE, I have the
at same personality disorder
visi.com as LUCY RICARDO!!
Jul 21 '06 #4

P: n/a
In message <12*************@corp.supernews.com>, Grant Edwards wrote:
On 2006-07-21, Lawrence D'Oliveiro <ld*@geek-central.gen.new_zealand>
wrote:
>In message <11*********************@s13g2000cwa.googlegroups. com>, gel
wrote:
>>I am attempting to understand threads to use in a network app which I
am writing.

It is written, somewhere in the philosophy of *nix programming, that
threads are a performance hack, to be avoided wherever possible. Use
processes in preference to threads.

I've never understood the aversion people seem to have to
threads.
Perhaps because with threads, data is shared by default. Whereas with
processes, it is private by default, and needs to be explicitly shared if
you want that.
Jul 22 '06 #5

P: n/a
In message <3h********************************@4ax.com>, Dennis Lee Bieber
wrote:
On Sat, 22 Jul 2006 17:19:22 +1200, Lawrence D'Oliveiro
<ld*@geek-central.gen.new_zealanddeclaimed the following in
comp.lang.python:
>>
Perhaps because with threads, data is shared by default. Whereas with
processes, it is private by default, and needs to be explicitly shared if
you want that.

Or just that the "name" "thread" was a late-comer for some of us...

The Amiga had "tasks" at the lowest level (these were what the core
OS library managed -- that core handled task switching, memory
allocation, and IPC [event flags, message ports]). "Processes" were
scheduled by the executive, but had additional data -- like stdin/stdout
and environment variables... all the stuff one could access from a
command line. Or, confusing for many... Processes were "DOS" level,
Tasks were "OS" level.
Or for a more up-to-date example, how about the Linux way, where "processes"
and "threads" are just two points on a spectrum of possibilities, all
controlled by options to the clone(2) system call.
Jul 22 '06 #6

P: n/a
On 2006-07-22, Lawrence D'Oliveiro <ld*@geek-central.gen.new_zealandwrote:
>I've never understood the aversion people seem to have to
threads.

Perhaps because with threads, data is shared by default.
Whereas with processes, it is private by default, and needs to
be explicitly shared if you want that.
Only global data is shared. I guess if you use a lot of global
data that's an issue. I tend not to. The problem with
processes is that sharing data is hard.

--
Grant Edwards grante Yow! Are you mentally here
at at Pizza Hut??
visi.com
Jul 22 '06 #7

P: n/a
Dennis Lee Bieber wrote:
On Sat, 22 Jul 2006 17:19:22 +1200, Lawrence D'Oliveiro
<ld*@geek-central.gen.new_zealanddeclaimed the following in
comp.lang.python:
>>
Perhaps because with threads, data is shared by default. Whereas with
processes, it is private by default, and needs to be explicitly shared if
you want that.

Or just that the "name" "thread" was a late-comer for some of us...

The Amiga had "tasks" at the lowest level (these were what the core
OS library managed -- that core handled task switching, memory
allocation, and IPC [event flags, message ports]). "Processes" were
scheduled by the executive, but had additional data -- like stdin/stdout
and environment variables... all the stuff one could access from a
command line. Or, confusing for many... Processes were "DOS" level,
Tasks were "OS" level.
On the Amiga, everything was essentially a "thread". There was *no* memory
protection whatsoever, which made for a wickedly fast -- and unstable --
OS.

Now, before Commordore went the way of the Dodo Bird, there was some
discussion about adding memory protection to the OS, but that was a very
difficult proposition since most if not all of the OS control structures
were just that -- basically c "structs", with live memory pointers handed
around from application to kernel and back.

I think we could've done it eventually, but that ship sank. All because of
the idiots there that was upper management. But I digress.

--
-- Edmond Dantes, CMC
And Now for something Completely Different:
http://baskets.giftsantiquescollectables.com
http://vacation-packages.YouDeserveItNow.com
http://cold-remedy.WomenLite.com
http://investments.BankOrLoan.com
http://coils.IndustrialMetalz.com
http://brackets.Auto1Parts.com
http://windmill.industrialtips.com
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
Jul 22 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.