Re: ssh popen stalling on password redirect output?
[EMAIL PROTECTED] wrote: > In general, it is good idea to use expect kind of tool to deal with > interactive programs like ssh. You may try using pexpect > (http://pexpect.sourceforge.net). > I tried tha once (on Solaris) and found that ssh could tell that pexpect wasn't a real tty and refused to connect. In the end, I had pexpect do a telnet 127.0.0.1, log in, then so ssh to the real destination. Pain in the ass but it worked. The Cog -- http://mail.python.org/mailman/listinfo/python-list
Re: question about deleting records from mysql
nephish wrote:
> Man, thanks for the link. and the tip. i am testing
> the db.commit() and printing the doc right now.
> thanks again.
If it's any help, using
cursor.execute("set autocommit = 1")
before doing anything else works nicely unless you actually need
transactions.
The Cog
--
http://mail.python.org/mailman/listinfo/python-list
Re: Making a timebomb
[EMAIL PROTECTED] wrote: > I have a server that right now runs infinitely. I'd like to make it > die after some amount of time. I was thinking of having a timebomb > thread that starts when the server starts. The timebomb sits, and > sleeps for the specified timeout period (e.g., 5 hours), then does > something to make the main thread terminate. But I'm too inexperienced > to figure out what that thing is. > > Any suggestions? > > > > class TimeBomb( threading.Thread ): >def run(self): >timeout = 5 * 60 * 60 #-- 3 hours >time.sleep( timeout ) >MakeTheRestOfTheStuffDie() > > class MyServer: >def __init__(self): >TimeBomb().run() >serve() > The proper way to do it is to have the timer set a flag that the other threads check regularly. The threads can then clean up and exit asap. The dirty way, which can leave corrupt half-written files and other nasties, is something like sys.exit(). The cog -- http://mail.python.org/mailman/listinfo/python-list
Re: Making a timebomb
Peter Hansen wrote: > Cantankerous Old Git wrote: > >> [EMAIL PROTECTED] wrote: >> >>> I have a server that right now runs infinitely. I'd like to make it >>> die after some amount of time. >> >> >> The proper way to do it is to have the timer set a flag that the other >> threads check regularly. The threads can then clean up and exit asap. >> >> The dirty way, which can leave corrupt half-written files and other >> nasties, is something like sys.exit(). > > > sys.exit() won't help you if your server is running in the main thread, > nor if your server thread is not marked as a daemon, but that does raise > another possibility. Instead of doing serve() in the main thread, spawn > off a child thread to do the serving, and call setDaemon(True) on it. > Then the _main_ thread can do sys.exit() and the server thread will be > terminated (somewhat messily perhaps) -- even if it is blocked in an > accept() call or some other external blocking call. I assume you know that I actually meant System.exit(). Why do you think that won't help? -- http://mail.python.org/mailman/listinfo/python-list
Re: Making a timebomb
Peter Hansen wrote: > Cantankerous Old Git wrote: > >> Peter Hansen wrote: >> >>> Cantankerous Old Git wrote: >>> >>>> The dirty way, which can leave corrupt half-written files and other >>>> nasties, is something like sys.exit(). >>> >>> >>> sys.exit() won't help you if your server is running in the main >>> thread, nor if your server thread is not marked as a daemon, but that >>> does raise another possibility. >> >> >> I assume you know that I actually meant System.exit(). Why do you >> think that won't help? > > > No, I didn't know that, but if you were confused the first time, I think > you're getting even more confused now. What is System.exit()? I don't > have one, and have never seen it mentioned. Perhaps you meant > SystemExit, the exception that's raised when you call sys.exit()? If > so, I still don't see your point, because there's no difference between > the two in this context. > > Maybe you meant os._exit()? Now *that* one is messy, and will work as > you described. > > -Peter Yup - I guess you're not interested in java.lang.System.exit() at all, are you. You're right about me getting confused! Perhaps I should take a break between reading the two newsgroups. Doh! sys.exit() docs (for Python) say it raises a SystemExit exception. A quick test shows that: * You can catch this to prevent being killed * It only gets raised on the calling thread - not the others So you're right - sys.exit is not very helpful in this case. os._exit is the one I was thinking of - equivalent to java's System.exit(). And to the OP, Bill - sorry for messing you around. As you see - I got confused. -- http://mail.python.org/mailman/listinfo/python-list
Re: how to write thread-safe module ? and pytz
Daniel Dittmar wrote: > Dictionaries (and probably most other Python types that are implemented > in C) are inherently thread safe. That sounds like a dangerous assumption to me. Are you relying on the Global Interpreter Lock? Is is guaranteed? Does that safety transfer to Jython? How can I tell if any particular object is thread-safe? I don't know the answers to these questions, and I have the feeling that it is probably best to play safe and always use your own explicit locking. The Cog -- http://mail.python.org/mailman/listinfo/python-list
Windows message pump problems
I am trying to write a program that I hope to get working as a
command-line app to start with, and then eventually use a windows
service wrapper to call it as a service. Its purpose is to attach
to an already running (not ours) service using an API DLL, where
it will do houskeeping and monitoring tasks.
This is where it all gets strange. Although I can make calls into
the API and do things proactively, when I register a callback for
event notification, this callback doesn't get called. I am told
that if I want event notifications, I must create a window and
run a "message pump" on it, and pass the window handle to the API
when I register my callback function. This is despite the fact
that I don't want my service to ever display a window. I gather I
don't have to act on any messages either, but somehow the API
won't tell me about any events unless I do this.
So I am trying to create a skeleton that will create a window and
run a "Message Pump". This is fairly succesful, in that I can
create the window and the API then magically calls my event handler.
But I want to be able to stop my service on demand, and this
involved killing the message pump loop and destroying the window.
I can't figure out how to do that.
Problem 1:
If I have another thread call DestroyWindow after a delay, it
gets an error "permission denied". I really can't see why.
Problem 2:
I thought that maybe catching some kind of message might help. I
have tried registering both a message-map and a wndProc handler.
In both instances (see the code below) I don't get the WM_CREATE
message that I hope to see first. Also, if I use the wndProc
method, the CPU slams to 100% and I seem to receive an infinite
number of messages of some sort.
Problem 3:
I thought if I pump the messages using GetMessage and
DispatchMessage in my own loop, I might be able to check a flag
and exit the loop when required. But I can't figure out the
callling arguments to these calls.
Below is the code I have done so far. I have stripped to as
simple as I can make it. I would really appreciate some guidance
or links to articles. I am struggling to understand even the
basics, I think.
The Cog.
import win32gui
import win32api
import win32con
import traceback, time, threading
def onCreate():
print 'GOT WM_CREATE'
def onDestroy():
print 'GOT WM_DESTROY'
def wndProc(hwnd, msg, wparam, lparam):
#print '~~~wndProc get a message'
if msg == win32con.WM_CREATE:
onCreate()
if msg == win32con.WM_DESTROY:
onDestroy()
return 0
def registerWindowClass():
wc = win32gui.WNDCLASS()
wc.hInstance = hinst
wc.lpszClassName = "Eric the half-a-bee"
messageMap = {win32con.WM_CREATE : onCreate ,
win32con.WM_DESTROY : onDestroy }
wc.lpfnWndProc = messageMap # no messages if I do this
#wc.lpfnWndProc = wndProc # infinite stream of
messages if I do this
return win32gui.RegisterClass(wc)
def createWindow(registeredClassAtom):
return win32gui.CreateWindow(
registeredClassAtom, "This is a window",
0, 0, 0, win32con.CW_USEDEFAULT, win32con.CW_USEDEFAULT,
0, 0, hinst, None)
hinst = win32api.GetModuleHandle(None)
hwnd = createWindow(registerWindowClass())
win32gui.ShowWindow(hwnd, True) # I'll try hide it later
win32gui.UpdateWindow(hwnd)
# wait 10 secs then kill the window
def timeKill():
print 'sleeping...'
time.sleep(10)
print 'killing'
win32gui.DestroyWindow(hwnd)
print 'starting killer timer'
threading.Thread(target=timeKill).start()
# This message pump traps the thread and never returns
win32gui.PumpMessages()
--
http://mail.python.org/mailman/listinfo/python-list
Re: Windows message pump problems
Neil Hodgson wrote: > Cantankerous Old Git: > >> Problem 1: >> If I have another thread call DestroyWindow after a delay, it gets an >> error "permission denied". I really can't see why. > > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowfunctions/destroywindow.asp > > > > """A thread cannot use DestroyWindow to destroy a window created by a > different thread.""" > >Posting WM_CLOSE to the window will probably work. If not, then send > an application defined message to the window and handle it by calling > DestroyWindow. > >Neil Sorry for the delay in answering. That put me on the right track, thanks. I post a custom message, and the handler calls DestroyWindow. The Cog -- http://mail.python.org/mailman/listinfo/python-list
