Re: SIGIO and AppKit main loop
Re: SIGIO and AppKit main loop
- Subject: Re: SIGIO and AppKit main loop
- From: Michael Rothwell <email@hidden>
- Date: Mon, 29 Mar 2004 07:55:20 -0500
One postscript:
Cocoa appears to have no equivalent of glib's "IO Channels," which are
really useful, and do not use threads. GIOChannel integrates with the
application's main thread and invokes callback functions for registered
events, such as ready-to-read, ready-to-write, ready-to-accept, etc. I
imagine it integrates the file descriptor in question with a
general-purpose select() or poll() done in the main application loop.
It looks like waitForDataInBackgroundAndNotify spawns a thread every
time it is called, which would be very inefficient for reading large
amounts of data. In fact, I can't think of any reason to ever use
waitForDataInBackgroundAndNotify rather than just starting a single
thread and sending notifications back from it while doing multiple I/O
operations.
http://developer.gnome.org/doc/API/2.0/glib/glib-IO-Channels.html#g-io-
add-watch
... where do I file an enhancement request? :D
Michael Rothwell, Mr. Async I/O Guy
email@hidden
On Mar 29, 2004, at 2:54 AM, Mike Davis wrote:
>
That's because dyld is not re-entrant. You'll probably be getting a
>
signal when a library is been opened and another dyld operation is
>
triggered to load another library. This would be a problem for any
>
mach binary you write, not just an AppKit one. You might play with
>
pre-binding but, essentially, you're stuck, as far as I can tell.
>
>
If you can re-code it in Cocoa, you could use the
>
readInBackgroundAndNotify methods of NSFileHandle. Of course, that's
>
expensive to do. It'll probably be easier for you to do it
>
synchronously and to do the blocking behaviour in a thread. I'm not
>
sure if NSFileHandle does async IO in the real sense. I suspect that
>
it does but it could always be a dumb poll.
>
>
My personal experience with async IO was some code I was working on
>
for a copy protection system (known as DRM nowadays). It was all done
>
in C/C++ in a framework using Project Builder. Essentially, all the
>
code we created was mach with GCC and the client was using Metrowerks
>
CFM (with some mach code in a framework).
>
>
I know the MSL signal code interfered with the real implementation so
>
I had to can it and use another technique instead (i.e. non async).
>
BTW, if you're hooking up with CW and MSL there're quite a few POSIX
>
functions that MSL implements when you compile mach that are left
>
overs from the old Classic compiler. "man 3 time" is one of them as I
>
recently recall.
>
>
You can bash CW to use the operating system libraries instead, but
>
it's not that straight forward.
>
>
BTW, off the top of my head I don't think signalling is thread
>
specific on the Mac. I might be wrong but it seems to ring a bell.
>
>
On 29 Mar 2004, at 03:29, Michael Rothwell wrote:
>
>
> Hm. Using the SIGIO-based code in a cocoa app causes this, but only
>
> occasionally ...
>
>
>
> "dyld operation attempted in a thread already doing a dyld operation"
>
>
>
> ... which is followed by an immediate crash. It looks like OSX checks
>
> for an attempted double-lock when loading libraries, and terminates
>
> the program that triggered the double-lock.
>
>
>
> I pass a callback to the C-based library with the code below. The
>
> only thing this app does, being a test jig, is append text read as a
>
> result of a SIGIO event to an NSTextView' s buffer. Maybe the local
>
> autorelease pool is busting things, I dunno.
>
>
>
> /********************************************************************/
>
> void
>
> ssdp_read_cb(const char *buf, void *user_data)
>
> {
>
> [user_data ssdpDataRead:buf];
>
> };
>
>
>
>
>
> /********************************************************************/
>
> -(void)ssdpDataRead:(char *)data
>
> {
>
> NSAutoreleasePool *p = [[NSAutoreleasePool alloc] init];
>
>
>
> NSLog(@"read:\n%s\n",data);
>
>
>
> [[m_tv textStorage] appendAttributedString:[[NSAttributedString
>
> alloc] initWithString:[NSString stringWithCString:data]] ];
>
> [m_tv display];
>
>
>
> [p release];
>
> };
>
>
>
> /********************************************************************/
>
> - (void)applicationDidFinishLaunching:(NSNotification *)aNotification
>
> {
>
> ssdp_init();
>
> ssdp_setReadCallback(&ssdp_read_cb, self);
>
> };
>
>
>
>
>
> Michael Rothwell
>
> email@hidden
>
>
>
> On Mar 28, 2004, at 8:45 PM, Michael Rothwell wrote:
>
>
>
>> So, long story short, if I don't intend to interact with
>
>> CodeWarrior-based code, I should be OK?
>
>>
>
>> Would SIGPOLL be preferable?
>
>>
>
>> Or is async I/O in general frowned upon with Cocoa? I'd be curious to
>
>> know of your 'personal experience' with async I/O on OSX.
>
>>
>
>> Thanks,
>
>>
>
>> -M
>
>>
>
>> p.s. what is "MSL?"
>
>>
>
>> Michael Rothwell
>
>> email@hidden
>
>>
>
>> On Mar 28, 2004, at 7:03 PM, John Stiles wrote:
>
>>
>
>>> CodeWarrior is fine if you can use the BSD libraries. (This is not
>
>>> the
>
>>> default, oddly.)
>
>>> If you have to use MSL, then yes, the POSIX layer demonstrates many
>
>>> goofy and nonstandard behaviors. Tread lightly :)
>
>>>
>
>>>
>
>>> On Mar 28, 2004, at 1:46 PM, Mike Davis wrote:
>
>>>
>
>>>> Speaking from personal experience, using async IO is bad news. It
>
>>>> works unless you have to be mixed in with CodeWarrior so beware.
>
>>>>
>
>>>> I switched to mach messaging (MIG) to avoid my problems as I was
>
>>>> developing a framework with GCC but the client was using CW
>
>>>> 8.something. Even worse, they were using CFM as a rule but had some
>
>>>> bits as mach with the crazy MSL versions of signalling, never mind
>
>>>> the regular POSIX APIs.
>
>>>>
>
>>>> On 28 Mar 2004, at 22:16, email@hidden wrote:
>
>>>>
>
>>>>> To: Cocoa Development <email@hidden>
>
>>>>> From: Michael Rothwell <email@hidden>
>
>>>>> Subject: SIGIO and AppKit main loop
>
>>>>> Date: Sun, 28 Mar 2004 11:57:29 -0500
>
>>>>>
>
>>>>> I used SIGIO to implement an asynchronous SSDP listener with
>
>>>>> callback
>
>>>>> notification, written in straight C.
>
>>>>>
>
>>>>> Will I experience any problems using this bit of code in a Cocoa
>
>>>>> application? In other words, will my use of SIGIO (and the
>
>>>>> associated
>
>>>>> signal handler) clash with anything AppKit does?
>
>>>>>
>
>>>>>
>
>>>>> Michael Rothwell
>
>>>>> email@hidden
>
>>>> _______________________________________________
>
>>>> cocoa-dev mailing list | email@hidden
>
>>>> Help/Unsubscribe/Archives:
>
>>>> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
>>>> Do not post admin requests to the list. They will be ignored.
>
>>> _______________________________________________
>
>>> cocoa-dev mailing list | email@hidden
>
>>> Help/Unsubscribe/Archives:
>
>>> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
>>> Do not post admin requests to the list. They will be ignored.
>
>> _______________________________________________
>
>> cocoa-dev mailing list | email@hidden
>
>> Help/Unsubscribe/Archives:
>
>> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
>> Do not post admin requests to the list. They will be ignored.
>
_______________________________________________
>
cocoa-dev mailing list | email@hidden
>
Help/Unsubscribe/Archives:
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.