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
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:
>
>
> >But the current code seems to assume a shared memory. Otherwise setting
> >the "owner" to the current PID is completely useless (except perhap
At 12:04 PM 7/24/2004 -0400, Pierre A. Humblet wrote:
>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 cent
On Sat, 24 Jul 2004, Pierre A. Humblet wrote:
> 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 d
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 ye
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 nec
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
On Jul 24 11:52, 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.
>
> Regarding the sharing/dup stuff, there are three different things to
> consider:
>
> 1. Independent processes
>
> T
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.
Regarding the sharing/dup stuff, there are three different things to
consider:
1. Independent processes
They should be able to open as many /dev/dsp devices as
On Thu, Jul 22, 2004 at 10:58:00AM -0400, Pierre A. Humblet wrote:
>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
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 wit
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 MapViewOfFileEx and with
> threads in perl,
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 MapViewOfFileEx and with
threads in perl, now, though. So, 1.5.11 is not quite cooked.
cgf
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 wond
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
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 (cygheap-
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 (cygheap->fdtab.find_archetype and others).
>My patch needs two addi
Hello Corinna, (and all other listeners)
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 (cygheap->fdtab.find_archetype and others).
My patch needs two additional pointers, so in t
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
21 matches
Mail list logo
