On Jul 31 12:03, Pierre A. Humblet wrote:
At 10:22 AM 7/30/2004 +0200, Corinna Vinschen wrote:
Hi Guys,
do we have any further news?
Barring news from Gerd, I will submit a proper patch.
Sounds good. May I suggest to submit only a patch to solve the dup
problem in the first place, so
At 10:22 AM 7/30/2004 +0200, Corinna Vinschen wrote:
Hi Guys,
do we have any further news?
Barring news from Gerd, I will submit a proper patch.
Pierre
Hi Guys,
do we have any further news?
Corinna
On Jul 26 21:33, Pierre A. Humblet wrote:
At 12:04 PM 7/24/2004 -0400, Pierre A. Humblet wrote:
snip
But the current code seems to assume a shared memory. Otherwise setting
the owner to the current PID is completely useless (except perhaps
At 12:04 PM 7/24/2004 -0400, Pierre A. Humblet wrote:
snip
But the current code seems to assume a shared memory. Otherwise setting
the owner to the current PID is completely useless (except perhaps
if a fork occurs while the device is playing. Doing that would be
an interesting test!) My 2 cents
Gert,
As a proof of concept, here is a patch that fixes dup and
cat xxx.wav /dev/dsp, under sh and bash (they use different
mechanisms). There is no linked list and no archetype, so some parameters
are still not shared between duped handles in the same process.
The fixes are as discussed
At 11:52 AM 7/24/2004 +0200, Gerd Spalink wrote:
After reading the discussion, I agree to give archetypes a try to fix dup.
I'll keep a copy of the linked list solution as a reference.
Gert,
I have the feeling that the main reason dup doesn't work is that
audioin_/out_ are not new'ed in the dup
Gert,
One reason why cat xxx.wav /dev/dsp doesn't work is that
the /dev/dsp driver sets close on exec. It shouldn't.
But it should have a fixup_after_exec.
One problem is that new calls calloc, and that won't be
preserved through execs. You need to use the cygheap
(ccalloc).
But is it necessary
Igor Pechtchanski wrote:
On Thu, 22 Jul 2004, Christopher Faylor wrote:
On Wed, Jul 21, 2004 at 11:25:19PM -0400, Pierre A. Humblet wrote:
Is it worth to delay 1.5.11 until those issues are sorted out?
No, I don't think so.
We do have people reporting problems with
At 08:38 PM 7/20/2004 -0400, Christopher Faylor wrote:
On Tue, Jul 20, 2004 at 11:58:23PM +0200, Gerd Spalink wrote:
Yes, I have had a look at archetypes, and I just checked again.
What I see is one instance counter (usecount) and a pointer (archetype)
and a dependency into cygheap
On Wed, Jul 21, 2004 at 11:12:22AM -0400, Pierre A. Humblet wrote:
Here is another idea.
As noted in your comments, the children cannot change any of the
parameters (because they don't have access to the parent). To fix that
I am wondering if it wouldn't be better to use a FileMapping that can
be
At 01:00 PM 7/21/2004 -0400, Christopher Faylor wrote:
On Wed, Jul 21, 2004 at 11:12:22AM -0400, Pierre A. Humblet wrote:
Here is another idea.
As noted in your comments, the children cannot change any of the
parameters (because they don't have access to the parent). To fix that
I am wondering if
On Jul 18 18:11, Gerd Spalink wrote:
What I did:
The static open_count is no longer needed because now we consistently
use the return status from the windows API to decide if we can open or not.
This change is not related to dup.
Wave header parsing needed a small fix. It was a +/-1
On Sun, 18 Jul 2004, Gerd Spalink wrote:
What I did:
The static open_count is no longer needed because now we consistently
use the return status from the windows API to decide if we can open or
not. This change is not related to dup.
Wave header parsing needed a small fix. It was a +/-1
13 matches
Mail list logo
