New to threads. How do they work?

[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(),())

 

[Dennis Lee Bieber]

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
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[gel]

Step one... Skip the thread module and use threading module instead.


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...


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
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
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

 

[Dennis Lee Bieber]

working so far. And another question why do you prefer to us threading
and thread?

As the documentation states, thread is a "low-level" method, and
only supplies a basic lock for synchronization.

threading is a higher-level interface, with more synchronization
capability...


--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Lawrence D'Oliveiro]

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.

 

[Grant Edwards]

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".

 

[Lawrence D'Oliveiro]

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.

 

[Dennis Lee Bieber]

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.
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Lawrence D'Oliveiro]

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.

 

[Grant Edwards]

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.

 

[Edmond Dantes]

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