Re: SIGIO and AppKit main loop
Re: SIGIO and AppKit main loop
- Subject: Re: SIGIO and AppKit main loop
- From: Mike Davis <email@hidden>
- Date: Mon, 29 Mar 2004 08:54:18 +0100
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.