[execnet-dev] closing channels and gateways

[holger krekel]

Hi Jacob,

On Fri, Nov 06, 2009 at 12:01 -0800, Jacob Perkins wrote:
> Hi Holger,
> 
> Following up after running my script w/ EXECNET_DEBUG, the trace file
> contains a bunch of "sent" lines, followed by a bunch of "received" lines,
> and ends with 10 "closing IO" lines. The traceback below happens once for
> each gateway (or channel), after my script prints it's final message. So I
> assume this happens in the atexit function, trying to close either a gateway
> or channel that had already been closed automatically. Seems like the
> easiest thing for me to do is simply to not bother with the atexit cleanup,
> and let execnet take care of closing everything down.

Makes sense but the issue probably persists, i am afraid. This example here:

    #./x.py 
    import execnet
    execnet.PopenGateway("python").remote_exec("")

if run with "python x.py" still often causes the traceback you showed.  
This is related to improper teardown. Needs further investigation ...

best,
holger

> Jacob
> 
> On Fri, Nov 6, 2009 at 10:41 AM, Jacob Perkins <japerk at gmail.com> wrote:
> 
> > Hi Holger,
> >
> > On Fri, Nov 6, 2009 at 9:42 AM, holger krekel <holger at merlinux.eu> wrote:
> >
> >> Hi Jacob,
> >>
> >> On Fri, Nov 06, 2009 at 08:05 -0800, Jacob Perkins wrote:
> >> > Do channels or gateways need to be explicitly closed before a script
> >> > finishes?
> >>
> >> Usually not.  But automatic teardown is a bit involved, tied to GC and
> >> __del__,
> >> not tested yet for all situations.
> >>
> >> > When I registered an atexit function to close them (calls close() on
> >> each
> >> > channel, then exit() on each gateway), I get the following:
> >> >
> >> > Traceback (most recent call last):
> >> >   File "<string>", line 1, in <module>
> >> >   File "<string>", line 979, in <module>
> >> >   File "<string>", line 688, in serve
> >> >   File "<string>", line 717, in executetask
> >> >   File "<string>", line 384, in close
> >> >   File "<string>", line 641, in _send
> >> >   File "<string>", line 185, in writeto
> >> >   File "<string>", line 884, in save
> >> >   File "<string>", line 161, in write
> >> > ValueError: I/O operation on closed file
> >>
> >> Is this execnet-1.0.0b2? (see execnet.__version__).
> >>
> >
> > Yes
> >
> >
> >> Is it part of a "RemoteError", i.e. a traceback-representation from
> >> remote?
> >>
> >
> > I believe so, I got multiple tracebacks at the end of my script, so I
> > believe I got one from each gateway (I had 1 channel per gateway, and 10
> > gateways open).
> >
> >
> >>
> >> This traceback comes from a process that finished executing
> >> a "remote_exec(source)" source code.  It tries to send
> >> a "close" message but the IO connection is already dead.
> >> This shouldn't happen in an automatic teardown, i'd say.
> >> So it's a bug - if you somehow find a script to reproduce it
> >> that'd be very helpful.
> >>
> >
> > The basic remote_exec is the following
> >
> > for fname in channel:
> >     # open file, do stuff
> >     channel.send(fname)
> >
> > Then in the main script I do the following (after opening gateways,
> > channels, and registering atexit function)
> >
> > multi = execnet.MultiChannel(channels)
> > queue = multi.make_receive_queue()
> >
> > for i in range(total): # total is the number of files sent to channels
> >     channel, fname = queue.get()
> >
> >
> >>
> >> With http://codespeak.net/execnet/trunk/basics.html#debugging-execnet
> >> you can get some trace-files of the several processes to see
> >> what is going on.
> >>
> >
> > Ok, I'll run my script with EXECNET_DEBUG.
> >
> >
> >>
> >> > Thanks (and huge thanks for creating execnet, it's simpler and far more
> >> > efficient for my purposes than discoproject)
> >>
> >> nice to hear!  What's your use case if i may ask?
> >>
> >
> > I'm using NLTK to do part of speech tagging and phrase chunking, so I start
> > a number of execnet nodes, send each two pickled NLTK objects, and then send
> > the nodes files to process. Since the NLTK objects can take a couple seconds
> > to unpickle, this is much more efficient than discoproject because the
> > unpickling only happens once at initialization, instead of once for every
> > file.
> >
> >
> >>
> >> best,
> >> holger
> >>
> >> --
> >> twitter: http://twitter.com/hpk42
> >> contracting: http://merlinux.eu
> >>
> >
> >
> >
> > --
> > http://streamhacker.com/
> >
> 
> 
> 
> -- 
> http://streamhacker.com/

--