«

I wonder if this is the right way to write a medusa(asyncore) server
with the win32all framework. Other example services seem to create an
event to pass the stop signal from SvcStop into a separate termination
method, but I'm unsure how that would mix with the polling loop.

This simple framework seems to start and stop OK, but I wonder if I'm
missing some obvious race or something.



import win32serviceutil, win32service,
class MeducaService(win32serviceutil.ServiceFramework):
_svc_name_ = "MedusaService"
_svc_display_name_ = "Medusa Service"
def __init__(self, args):
win32serviceutil.ServiceFramework.__init__(self, args)

def SvcStop(self):
self.ReportServiceStatus(win32service.SERVICE_STOP _PENDING)
print "Received Quit from Win32"
socket_map = asyncore.socket_map
while socket_map:
k, v = socket_map.popitem()
try:
print "Shutting down",k,v
v.close()
except:
pass
del k, v

def SvcDoRun(self):
start_medusa()

--
Robin Becker

Hi,

Before I start the trial & error -cycle,
has anybody tried to start Bash -shell
script in Cygwin environment
from Python running in W2K?

True, Cygwin has Python package available, but I would like to
use true W2K version of Python. This would be the first
step of gradual conversion of all the shell scripts in Cygwin
to true W2K Python scripts: I would initially have WxPython Menu
in W2K from which I start Cygwin scripts.

-pekka-

Robin Becker wrote:

> I wonder if this is the right way to write a medusa(asyncore) server
> with the win32all framework. Other example services seem to create an
> event to pass the stop signal from SvcStop into a separate termination
> method, but I'm unsure how that would mix with the polling loop.
>
> This simple framework seems to start and stop OK, but I wonder if I'm
> missing some obvious race or something.

SvcStop will be called on a different thread. I don't know enough about
socket semantics to know if this is an issue.

When I've tried to play with async based services, IIRC there were a few
problems if a connection existed at shutdown time. If "close" could
ever block, then Windows would get quite upset. If a "close()" ever
fails, then I guess there is a risk that the main loop will not
terminate, again making Windows upset. But as above, I don't know
enough about the framework to comment on the risks here.

So really, the issues are all Python related - the win32 interactions
appear OK, assuming close could never block.

For the SpamBayes project, our framework needed a "clean shutdown" to
save our databases etc, so we ended up using urlopen to connect to a
special "shutdown" URL. I didn't write that part, so I don't understand
if there was a better option.

Hope this helps a little

Mark.

Robin Becker <> wrote in message news:<WnWU+VAnDjy$>...
> I wonder if this is the right way to write a medusa(asyncore) server
> with the win32all framework. Other example services seem to create an
> event to pass the stop signal from SvcStop into a separate termination
> method, but I'm unsure how that would mix with the polling loop.
>
> This simple framework seems to start and stop OK, but I wonder if I'm
> missing some obvious race or something.

I think the cleanest design for this is to use the
medusa.threading.select_trigger function to send an asyncore.ExitNow
exception into the main select loop. The only problem with this is
that the current medusa.threading.select_trigger (in the sourceforge
medusa version) catches (and does not re-raise) this exception. I've
modified our code so that it does not catch it and this seems to work
very well (we have a web server using medusa that runs as a service).

Regards,
Giles Brown

In article <bqdvv2$2m5u$>, Mark Hammond
<> writes
>Robin Becker wrote:
>
>> I wonder if this is the right way to write a medusa(asyncore) server
>> with the win32all framework. Other example services seem to create an
>> event to pass the stop signal from SvcStop into a separate termination
>> method, but I'm unsure how that would mix with the polling loop.
>>
>> This simple framework seems to start and stop OK, but I wonder if I'm
>> missing some obvious race or something.
>
>SvcStop will be called on a different thread. I don't know enough about
>socket semantics to know if this is an issue.
>

>When I've tried to play with async based services, IIRC there were a few
>problems if a connection existed at shutdown time. If "close" could
>ever block, then Windows would get quite upset. If a "close()" ever
>fails, then I guess there is a risk that the main loop will not
>terminate, again making Windows upset. But as above, I don't know
>enough about the framework to comment on the risks here.
>
>So really, the issues are all Python related - the win32 interactions
>appear OK, assuming close could never block.
>
>For the SpamBayes project, our framework needed a "clean shutdown" to
>save our databases etc, so we ended up using urlopen to connect to a
>special "shutdown" URL. I didn't write that part, so I don't understand
>if there was a better option.
>
>Hope this helps a little
>

it does indeed as I'm then into ensuring that the close methods are
reasonable. So I guess the problem reduces to whether the simple medusa
services ftp/http are cleanly terminatable.

As a matter of interest how does one get rid of LEGACY services? Whilst
getting the above going I seem to have created a LEGACY_MEDUSASERVICE in
the registry. All attempts at deletion fail.

>Mark.
>

--
Robin Becker

In article < >, Giles
Brown <> writes
>Robin Becker <> wrote in message news:<WnWU+VAnDjy$EwE
>>...
>> I wonder if this is the right way to write a medusa(asyncore) server
>> with the win32all framework. Other example services seem to create an
>> event to pass the stop signal from SvcStop into a separate termination
>> method, but I'm unsure how that would mix with the polling loop.
>>
>> This simple framework seems to start and stop OK, but I wonder if I'm
>> missing some obvious race or something.
>
>I think the cleanest design for this is to use the
>medusa.threading.select_trigger function to send an asyncore.ExitNow
>exception into the main select loop. The only problem with this is
>that the current medusa.threading.select_trigger (in the sourceforge
>medusa version) catches (and does not re-raise) this exception. I've
>modified our code so that it does not catch it and this seems to work
>very well (we have a web server using medusa that runs as a service).
>
>Regards,
>Giles Brown
well it is an opensource project, so perhaps you could submit patches.
I'm not sure how much work A Kuchling would/could devote to it. I also
have made some relatively trivial changes to the status extension, but
they don't affect very much.
--
Robin Becker

Pekka,

On Sun, Nov 30, 2003 at 09:12:12PM +0200, Pekka Niiranen wrote:
> Before I start the trial & error -cycle, has anybody tried to start
> Bash -shell script in Cygwin environment from Python running in W2K?

Something like the following should meet your needs:

Python ... [MSC 32 bit (Intel)] on win32
>>> import os
>>> os.system('bash ~/bin/foo.sh')
foo
0

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

I have used w32python interactively from a cygwin bash. its okay.
but I think I remember that the python environment (syspath?) was not
set properly. so, this would be something to check in your cygwin
bash rc file..

--
David Bear
phone: 480-965-8257
fax: 480-965-9189
College of Public Programs/ASU
Wilson Hall 232
Tempe, AZ 85287-0803
"Beware the IP portfolio, everyone will be suspect of trespassing"