* [Fwd: [gp@familiehaase.de: sem_* functions in cygwin]]
@ 2004-12-09 16:42 Corinna Vinschen
2004-12-09 16:50 ` Mark Paulus
2004-12-12 13:54 ` Gerrit P. Haase
0 siblings, 2 replies; 7+ messages in thread
From: Corinna Vinschen @ 2004-12-09 16:42 UTC (permalink / raw)
To: cygwin
[Catching up on some older mails]
> ----- Forwarded message from "Gerrit P. Haase" -----
> From: "Gerrit P. Haase"
> To: cygwin ML
> Subject: sem_* functions in cygwin
> Date: Sun, 21 Nov 2004 22:48:20 +0100
>
> Hi,
>
> nearly all sem_* functions are available, but sem_unlock is missing,
> was there a problem implementing sem_unlock() or was it just missed
> by accident?
>
>
> Gerrit
> ----- End forwarded message -----
I guess you're asking about sem_unlink(). It's not implemented so far
since named POSIX semaphores are implemented using named Windows semaphores.
The SUSv3 description contains a pretty unfortunate implementation detail:
Calls to sem_open() to recreate or reconnect to the semaphore refer
to a new semaphore after sem_unlink() is called.
There's no way I know of, which allows to implement this using named
Windows semaphores. At least not without adding a lot of annoying
bookkeeping overhead, possibly involving cygserver.
Corinna
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Fwd: [gp@familiehaase.de: sem_* functions in cygwin]]
2004-12-09 16:42 [Fwd: [gp@familiehaase.de: sem_* functions in cygwin]] Corinna Vinschen
@ 2004-12-09 16:50 ` Mark Paulus
2004-12-09 17:02 ` Corinna Vinschen
2004-12-12 13:54 ` Gerrit P. Haase
1 sibling, 1 reply; 7+ messages in thread
From: Mark Paulus @ 2004-12-09 16:50 UTC (permalink / raw)
To: cygwin
So, does that mean that if process 1 opens a semaphore,
process 2 also grabs it, then process 1 unlinks it, and then
"reconnects" to it, that process 1 and process 2 do not have
and cannot have the same semaphore anymore, even though
they are using the same IPC_KEY?
(Or am I way confused/off base here)?
On Thu, 09 Dec 2004 17:44:42 +0100, Corinna Vinschen wrote:
>[Catching up on some older mails]
>> ----- Forwarded message from "Gerrit P. Haase" -----
>> From: "Gerrit P. Haase"
>> To: cygwin ML
>> Subject: sem_* functions in cygwin
>> Date: Sun, 21 Nov 2004 22:48:20 +0100
>>
>> Hi,
>>
>> nearly all sem_* functions are available, but sem_unlock is missing,
>> was there a problem implementing sem_unlock() or was it just missed
>> by accident?
>>
>>
>> Gerrit
>> ----- End forwarded message -----
>I guess you're asking about sem_unlink(). It's not implemented so far
>since named POSIX semaphores are implemented using named Windows semaphores.
>The SUSv3 description contains a pretty unfortunate implementation detail:
> Calls to sem_open() to recreate or reconnect to the semaphore refer
> to a new semaphore after sem_unlink() is called.
>There's no way I know of, which allows to implement this using named
>Windows semaphores. At least not without adding a lot of annoying
>bookkeeping overhead, possibly involving cygserver.
>Corinna
>--
>Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
>Problem reports: http://cygwin.com/problems.html
>Documentation: http://cygwin.com/docs.html
>FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Fwd: [gp@familiehaase.de: sem_* functions in cygwin]]
2004-12-09 16:50 ` Mark Paulus
@ 2004-12-09 17:02 ` Corinna Vinschen
0 siblings, 0 replies; 7+ messages in thread
From: Corinna Vinschen @ 2004-12-09 17:02 UTC (permalink / raw)
To: cygwin
On Dec 9 09:50, Mark Paulus wrote:
> So, does that mean that if process 1 opens a semaphore,
> process 2 also grabs it, then process 1 unlinks it, and then
> "reconnects" to it, that process 1 and process 2 do not have
> and cannot have the same semaphore anymore, even though
> they are using the same IPC_KEY?
>
> (Or am I way confused/off base here)?
Only partially. IPC_KEYs have nothing to do with it since we're talking
about *POSIX* semaphores, not *SYSV* semaphores.
Otherwise you're right. After some process has called sem_unlink(), any
subsequent call to sem_open with the same sempahore name connects to a new
semaphore.
Corinna
>
> On Thu, 09 Dec 2004 17:44:42 +0100, Corinna Vinschen wrote:
>
> >[Catching up on some older mails]
>
> >> ----- Forwarded message from "Gerrit P. Haase" -----
> >> From: "Gerrit P. Haase"
> >> To: cygwin ML
> >> Subject: sem_* functions in cygwin
> >> Date: Sun, 21 Nov 2004 22:48:20 +0100
> >>
> >> Hi,
> >>
> >> nearly all sem_* functions are available, but sem_unlock is missing,
> >> was there a problem implementing sem_unlock() or was it just missed
> >> by accident?
> >>
> >>
> >> Gerrit
> >> ----- End forwarded message -----
>
> >I guess you're asking about sem_unlink(). It's not implemented so far
> >since named POSIX semaphores are implemented using named Windows semaphores.
> >The SUSv3 description contains a pretty unfortunate implementation detail:
>
> > Calls to sem_open() to recreate or reconnect to the semaphore refer
> > to a new semaphore after sem_unlink() is called.
>
> >There's no way I know of, which allows to implement this using named
> >Windows semaphores. At least not without adding a lot of annoying
> >bookkeeping overhead, possibly involving cygserver.
>
>
> >Corinna
>
> >--
> >Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
> >Problem reports: http://cygwin.com/problems.html
> >Documentation: http://cygwin.com/docs.html
> >FAQ: http://cygwin.com/faq/
>
>
>
>
>
> --
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
> Problem reports: http://cygwin.com/problems.html
> Documentation: http://cygwin.com/docs.html
> FAQ: http://cygwin.com/faq/
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:cygwin@cygwin.com
Red Hat, Inc.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Fwd: [gp@familiehaase.de: sem_* functions in cygwin]]
2004-12-09 16:42 [Fwd: [gp@familiehaase.de: sem_* functions in cygwin]] Corinna Vinschen
2004-12-09 16:50 ` Mark Paulus
@ 2004-12-12 13:54 ` Gerrit P. Haase
2004-12-20 11:23 ` Gerrit P. Haase
2004-12-20 12:13 ` [Fwd: [sem_* " Corinna Vinschen
1 sibling, 2 replies; 7+ messages in thread
From: Gerrit P. Haase @ 2004-12-12 13:54 UTC (permalink / raw)
To: cygwin
Corinna Vinschen wrote:
> [Catching up on some older mails]
>
>
>>----- Forwarded message from "Gerrit P. Haase" -----
>>From: "Gerrit P. Haase"
>>To: cygwin ML
>>Subject: sem_* functions in cygwin
>>Date: Sun, 21 Nov 2004 22:48:20 +0100
>>
>>Hi,
>>
>>nearly all sem_* functions are available, but sem_unlock is missing,
>>was there a problem implementing sem_unlock() or was it just missed
>>by accident?
>>
>>
>>Gerrit
>>----- End forwarded message -----
>
>
> I guess you're asking about sem_unlink(). It's not implemented so far
> since named POSIX semaphores are implemented using named Windows semaphores.
> The SUSv3 description contains a pretty unfortunate implementation detail:
>
> Calls to sem_open() to recreate or reconnect to the semaphore refer
> to a new semaphore after sem_unlink() is called.
>
> There's no way I know of, which allows to implement this using named
> Windows semaphores. At least not without adding a lot of annoying
> bookkeeping overhead, possibly involving cygserver.
I got an undefined reference to sem_unlock().
Gerrit
--
=^..^=
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Fwd: [gp@familiehaase.de: sem_* functions in cygwin]]
2004-12-12 13:54 ` Gerrit P. Haase
@ 2004-12-20 11:23 ` Gerrit P. Haase
2004-12-20 12:23 ` Corinna Vinschen
2004-12-20 12:13 ` [Fwd: [sem_* " Corinna Vinschen
1 sibling, 1 reply; 7+ messages in thread
From: Gerrit P. Haase @ 2004-12-20 11:23 UTC (permalink / raw)
To: cygwin
Gerrit P. Haase wrote:
> Corinna Vinschen wrote:
>
>> [Catching up on some older mails]
>>
>>
>>> ----- Forwarded message from "Gerrit P. Haase" -----
>>> From: "Gerrit P. Haase" To: cygwin ML
>>> Subject: sem_* functions in cygwin
>>> Date: Sun, 21 Nov 2004 22:48:20 +0100
>>>
>>> Hi,
>>>
>>> nearly all sem_* functions are available, but sem_unlock is missing,
>>> was there a problem implementing sem_unlock() or was it just missed
>>> by accident?
>>>
>>>
>>> Gerrit
>>> ----- End forwarded message -----
>>
>>
>>
>> I guess you're asking about sem_unlink(). It's not implemented so far
>> since named POSIX semaphores are implemented using named Windows
>> semaphores. The SUSv3 description contains a pretty unfortunate
>> implementation detail:
>>
>> Calls to sem_open() to recreate or reconnect to the semaphore refer
>> to a new semaphore after sem_unlink() is called.
>>
>> There's no way I know of, which allows to implement this using named
>> Windows semaphores. At least not without adding a lot of annoying
>> bookkeeping overhead, possibly involving cygserver.
>
>
> I got an undefined reference to sem_unlock().
I don't remember now which package it was, however there is a maro
used in linux which is based on ipc_unlock():
#define sem_unlock(id) ipc_unlock(&sem_ids,id)
http://www.iglu.org.il/lxr/ident?i=sem_unlock
Gerrit
--
=^..^=
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Fwd: [sem_* functions in cygwin]]
2004-12-12 13:54 ` Gerrit P. Haase
2004-12-20 11:23 ` Gerrit P. Haase
@ 2004-12-20 12:13 ` Corinna Vinschen
1 sibling, 0 replies; 7+ messages in thread
From: Corinna Vinschen @ 2004-12-20 12:13 UTC (permalink / raw)
To: cygwin
[Oops, I've sent this to Gerrit by PM instead of to the list.
Just resending it now for the records]
On Dec 12 14:54, Gerrit P. Haase wrote:
> Corinna Vinschen wrote:
> >>----- Forwarded message from "Gerrit P. Haase" -----
> >>nearly all sem_* functions are available, but sem_unlock is missing,
> >>was there a problem implementing sem_unlock() or was it just missed
> >>by accident?
> >>Gerrit
> >>----- End forwarded message -----
> >
> >I guess you're asking about sem_unlink(). It's not implemented so far
> >since named POSIX semaphores are implemented using named Windows
> >semaphores. The SUSv3 description contains a pretty unfortunate
> >implementation detail:
> >
> > Calls to sem_open() to recreate or reconnect to the semaphore refer
> > to a new semaphore after sem_unlink() is called.
> >
> >There's no way I know of, which allows to implement this using named
> >Windows semaphores. At least not without adding a lot of annoying
> >bookkeeping overhead, possibly involving cygserver.
>
> I got an undefined reference to sem_unlock().
There's no such function defined in SUSv3.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:cygwin@cygwin.com
Red Hat, Inc.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Fwd: [gp@familiehaase.de: sem_* functions in cygwin]]
2004-12-20 11:23 ` Gerrit P. Haase
@ 2004-12-20 12:23 ` Corinna Vinschen
0 siblings, 0 replies; 7+ messages in thread
From: Corinna Vinschen @ 2004-12-20 12:23 UTC (permalink / raw)
To: cygwin
On Dec 20 12:23, Gerrit P. Haase wrote:
> Gerrit P. Haase wrote:
> >I got an undefined reference to sem_unlock().
>
> I don't remember now which package it was, however there is a maro
> used in linux which is based on ipc_unlock():
> #define sem_unlock(id) ipc_unlock(&sem_ids,id)
>
> http://www.iglu.org.il/lxr/ident?i=sem_unlock
That's inside the Linux kernel. There's no such function or macro
defined on the API side of Linux.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:cygwin@cygwin.com
Red Hat, Inc.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-12-20 12:23 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-12-09 16:42 [Fwd: [gp@familiehaase.de: sem_* functions in cygwin]] Corinna Vinschen
2004-12-09 16:50 ` Mark Paulus
2004-12-09 17:02 ` Corinna Vinschen
2004-12-12 13:54 ` Gerrit P. Haase
2004-12-20 11:23 ` Gerrit P. Haase
2004-12-20 12:23 ` Corinna Vinschen
2004-12-20 12:13 ` [Fwd: [sem_* " Corinna Vinschen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).