• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Yet another problem with NSTask and NSPipe
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Yet another problem with NSTask and NSPipe


  • Subject: Re: Yet another problem with NSTask and NSPipe
  • From: Dragan Milić <email@hidden>
  • Date: Sun, 22 Apr 2007 16:57:49 +0200

Response to both Andreas and Thomas:

On ned 22. 04. 2007., at 16:07, Thomas Engelmeier wrote:

Am 22.04.2007 um 14:16 schrieb Dragan Milić:

Preample: I've used NSPipe'd NSTasks successfully on 2 GHz CoreDuo machines w/o any problem, even for short running processes. It was rather tricky, though, to get piping between tasks right (data got lost until the order was waterproof). You ARE already piping (/usr/ bin/env << hdiutil), I'd eliminate this for testing

I did that, so setting '/usr/bin/hdiutil' as launch path, but the problem remained. Anyway, I'll take this advice, and modify the code that it doesn't use '/usr/bin/env' anymore.


NSTask *task = [[[NSTask alloc] init] autorelease];
[...]
	[task launch];
	[task waitUntilExit];
	int terminationStatus = [task terminationStatus];

Bug here: task is autoreleased:

Hmmm, this "autorelease" has probably crept in while copy/pasting various portions/examles of code into the message text. It's not in the real code, please pretend it's not in my first message in this thread too :-)l


Bug 2: You can NOT be sure all data was already received here, but the pipe will be terminated here

	[task release];
	if (terminationStatus != 0) {
		// error handling
	}

Yep, that's the problem! I assumed that once the task is ended ([task waitUntilExit]) all the output has already been received. The code from Andreas' AMShellWrapper pointed the fact that in may not be the case.


ous approaches and everything that I could find on mailing lists on NSTask and NSPipe topics and that I could think of, including pooling file descriptor of stdOutHandle with select() and setting it to O_NONBLOCK, reading in separate thread, putting delays in the main method, postponing removing of object from notification center until later,
postponing releasing of NSTask object until later,... None of it helped.

Take the Moriarty sample and modify it for your NSTask

That's exactly what Andreas did with his AMShellWrapper, so I'll try to use that.


Can anyone point to me the correct way of doing this, which will discard all possible timing issues? Any help is much appreciated.

Pretty complex, actually, especially if you also allow cancelling the NSTask.

Luckily, I don't need to allow canceling, at least not for now.

Thanks a lot,

Milke


_______________________________________________

Cocoa-dev mailing list (email@hidden)

Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Yet another problem with NSTask and NSPipe
      • From: Gerd Knops <email@hidden>
References: 
 >Yet another problem with NSTask and NSPipe (From: Dragan Milić <email@hidden>)
 >Re: Yet another problem with NSTask and NSPipe (From: Thomas Engelmeier <email@hidden>)

  • Prev by Date: Re: Yet another problem with NSTask and NSPipe
  • Next by Date: Re: NSOpenPanel -runModalForDirectory:file:types: won't select file
  • Previous by thread: Re: Yet another problem with NSTask and NSPipe
  • Next by thread: Re: Yet another problem with NSTask and NSPipe
  • Index(es):
    • Date
    • Thread