On Thu, Nov 15, 2007 at 11:37:51AM -0800, [EMAIL PROTECTED] wrote: > > - I've taken the subprocess module, ripped out its Windows half and > > turned Popen into Mopen, which forks off and runs a method, rather than > > forking and execing. There's some weirdness here I'm not entirely sure > > about, but it's been working pretty well for me so far. > > What kind of weirdness are you seeing?
Well, there's the comment in the __main__ section, for starters. That's the issue that concerns me more. And there's the one on line 207. In some sense, Popen() is simpler because if the child process throws a stack trace, it happens immediately -- i.e., the exec fails -- and all of this can be returned to the parent on a separate file descriptor. But in Mopen(), if there's a stack trace, it won't necessarily be immediate, but we don't want the parent to hang around waiting, since that defeats the entire purpose of forking. So I just wrapped the stack trace into stderr. I'm probably conflating a couple of separate issues, and I'm not sure how often any of this will actually cause problems, so I just left it as is. > You're grabbing a lock in a signal handler, which can cause a deadlock if > you take a signal on top of the owner of the lock. It doesn't look like > that can happen in this case. If for no other reason than we're not forking any other time than this once. That may chance in the future, though. > (Do you know how, or in what context, the signal handlers get executed in > Python?) I don't. The documentation for the signal module is unhelpful in this regard. > I'm also assuming that the catalog isn't multithreaded, even though > you've imported the threading module. (Just for the lock, correct?) Right. > Would update the comment at catalog:101 to include exactly which > portions of the catalog state are protected by the lock? Is "We need to lock the search database" not enough? Note that the current comment doesn't actually say anything about catalogs. > It would be cool if we could extend Lock to contain the owner of the lock > so that we could implement a Python version of MUTEX_HELD(). Then in > update_index we could assert LOCK_HELD for its callers. We can file an > RFE for this and do it later, though. Sure. Thanks, Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
