site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:references :in-reply-to:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; bh=nNU9mPiMiwxVuxMgwjLXV8PuAGszpzKoH/XK9kJCSXY=; b=efR809A+LROA44guH6PDa+CSwN5Gd/luHuKWuxbYm/xX49pSEC/FlxXy7Fy/2m5aji orEP1wAasEbOqNvpSNRcI81QbAHsCx3CnwLXxMQRDuVMy1mPLmpyzZz3RawRHfreorbv XUrZG/X3UzlpcXuNOWy0Q+9UmTHVKzJyNhUMM= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=oUA6ySnw2gQqXXVVheezr1BhTmYkFcTdeiQTd7KxNCJ4CHU7vXCq8CfEVGCnt/QpJ3 dLt+tKkLfI6uWuE6Ie4x12ho+V+Wkdv/7lVV7A53JoUwaJhO478F10mpjUbju2PQcm2/ zWiCwSt3s2XZYMwkA0pGVAl8jG2Pdz8J1B3NM= Untested theory: can you use alarm/setitimer with SysV style semaphores? I believe SIGALRM is a synchronous signal, so would be delivered on the thread you set it on. Then you'd check your sem calls for EINTR. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/tyler.sample%40gmail.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... I had a lot of strange buggy behavior when I tried the SIGALRM approach. I didn't spend too much time digging into it with gdb or anything because the time precision (1 second intervals) might not be adequate for the performance needs of the application anyway. Also, this approach has been suggested for this problem elsewhere, and I've never seen a "that worked" response, so I'm not sure about it. If anyone has tried it and had it work, I'd love to hear it. I've thought about a similar tact where I spawn another thread to perform the blocking call on the semaphore, and then use timeoutable pthread synchs between it and the main thread, but given the app's semaphore use, I'm really not sure how many hung threads the task might end up with. Maybe acceptable, I guess, but ridiculously complicated and certainly far from optimal, especially later for anyone else trying to debug a threading issue or the like... Obviously, there's probably solutions that don't require this semaphore for the application as a whole and are more optimal. Unfortunately, I'm working in an OS abstraction layer and modifying all the code outside of it to work with some other mechanism just isn't feasible in the time I have...which I've used half of just trying to solve this one problem. Regarding this: <abdulla.kamar@gmail.com> From what I understand, you should be able to pass a mach semaphore over a mach port to the other process and then use semaphore_timedwait. The structure of the mach semaphore itself, which is actually a mach port right, is not valid across a task/process boundary (KERN_INVALID_NAME). Mach mechanisms seem to exist for passing port rights to another task. I guess what I need is the ability to put those port rights in named storage, probably a port, so any other task that knows the name can pick them up. If anybody more familiar with mach than me could provide any guidance, I'd certainly be appreciative, but I basically don't know mach well enough to implement cross-process semaphores in it myself. There's an open source project called Firebird that may have had luck with this approach, but I can't make heads or tails of their newest semaphore code for OSX. ----- Original Message ----- From: "Stephen J. Butler" <stephen.butler@gmail.com> To: "Darwin Dev" <darwin-dev@lists.apple.com> Sent: Wednesday, November 11, 2009 4:50 PM Subject: Re: cross-process timeoutable semaphores On Wed, Nov 11, 2009 at 4:18 PM, Tyler Sample <tyler.sample@gmail.com> wrote: POSIX semaphores won't work because OSX doesn't support sharing them across processes. Carbon's "multiprocess services" also, strangely, doesn't work across process boundaries. System V style semaphores are missing the ability to timeout (on OSX) This email sent to tyler.sample@gmail.com This email sent to site_archiver@lists.apple.com