I know phobos is nto usable without a gc but is druntime usable without
having a GC?
--
Kind Regards
Benjamin Thaut
On Dec 2, 2011, at 8:57 AM, Benjamin Thaut wrote:
> I know phobos is nto usable without a gc but is druntime usable without
> having a GC?
You'll leak when threads terminate (they're allocated by the GC and not safe
for the user to delete), but I think that's it for user-visible code. Some
ar
Am 02.12.2011 20:29, schrieb Sean Kelly:
On Dec 2, 2011, at 8:57 AM, Benjamin Thaut wrote:
I know phobos is nto usable without a gc but is druntime usable without having
a GC?
You'll leak when threads terminate (they're allocated by the GC and not safe
for the user to delete), but I think t
I could really use one. Not for real use but to test a bit with.
So if you really make one, host it at github or something like that.
>
> Thanks, That doesn't sound to bad. If I manage to get a non leaking non
> gc version of d-runtime working would there be any interest in that?
>
Absolutely, judging by the number of related discussions on IRC there will
be many developers who would be interested in such project.
Am 03.12.2011, 10:01 Uhr, schrieb Benjamin Thaut :
Thanks, That doesn't sound to bad. If I manage to get a non leaking non
gc version of d-runtime working would there be any interest in that?
Kind Regards
Benjamin Thaut
That would be most interesting! How do you imagine this could work thou
+1 on interest on having this. Back when I was attempting to port VST
to D I got asked by a Steinberg dev how I can guarantee that D plugins
will work. But I couldn't guarantee it, if a GC collection were to run
the plugin would freeze, the host would crash, and the host company
would likely get th
Am 03.12.2011, 19:05 Uhr, schrieb Andrej Mitrovic
:
+1 on interest on having this. Back when I was attempting to port VST
to D I got asked by a Steinberg dev how I can guarantee that D plugins
will work. But I couldn't guarantee it, if a GC collection were to run
the plugin would freeze, the h
On 12/3/11, Marco Leise wrote:
> Am 03.12.2011, 19:05 Uhr, schrieb Andrej Mitrovic
> :
>
>> +1 on interest on having this. Back when I was attempting to port VST
>> to D I got asked by a Steinberg dev how I can guarantee that D plugins
>> will work. But I couldn't guarantee it, if a GC collection
Am 03.12.2011, 19:47 Uhr, schrieb Andrej Mitrovic
:
On 12/3/11, Marco Leise wrote:
Am 03.12.2011, 19:05 Uhr, schrieb Andrej Mitrovic
:
+1 on interest on having this. Back when I was attempting to port VST
to D I got asked by a Steinberg dev how I can guarantee that D plugins
will work. But
On 2011-12-03 19:05, Andrej Mitrovic wrote:
+1 on interest on having this. Back when I was attempting to port VST
to D I got asked by a Steinberg dev how I can guarantee that D plugins
will work. But I couldn't guarantee it, if a GC collection were to run
the plugin would freeze, the host would c
On 04.12.2011 12:53, Jacob Carlborg wrote:
On 2011-12-03 19:05, Andrej Mitrovic wrote:
+1 on interest on having this. Back when I was attempting to port VST
to D I got asked by a Steinberg dev how I can guarantee that D plugins
will work. But I couldn't guarantee it, if a GC collection were to r
On 04.12.2011 09:10, Marco Leise wrote:
Am 03.12.2011, 19:47 Uhr, schrieb Andrej Mitrovic
:
On 12/3/11, Marco Leise wrote:
Am 03.12.2011, 19:05 Uhr, schrieb Andrej Mitrovic
:
+1 on interest on having this. Back when I was attempting to port VST
to D I got asked by a Steinberg dev how I can
You can make the GC know about any thread you want. Look at thread_attachThis
and related routines in core.thread.
Sent from my iPhone
On Dec 4, 2011, at 5:08 AM, Norbert Nemec wrote:
> On 04.12.2011 09:10, Marco Leise wrote:
>> Am 03.12.2011, 19:47 Uhr, schrieb Andrej Mitrovic
>> :
>>
>>> O
Indeed, but here the issue is actually opposite: you *don't* want the GC
to know about the audio-thread.
On 04.12.2011 18:05, Sean Kelly wrote:
You can make the GC know about any thread you want. Look at thread_attachThis
and related routines in core.thread.
Sent from my iPhone
On Dec 4, 2
On 12/4/2011 5:08 AM, Norbert Nemec wrote:
Indeed, malloc is not real-time safe. It is common wisdom that real-time audio
code should not handle any memory allocations.
To this point, D is just as safe as C++: don't do any operations that may
allocate memory in the audio thread, so the GC will n
On 12/4/11, Marco Leise wrote:
> Hmm, and no one commented either. I thought someone would jump in and say
> that you could disable the GC.
Right, I've heard this story before but has anyone actually tried
using D without the GC? I'm genuinely curious. I'd also wonder how
usable D would be withou
On 12/04/2011 09:56 PM, Andrej Mitrovic wrote:
On 12/4/11, Marco Leise wrote:
Hmm, and no one commented either. I thought someone would jump in and say
that you could disable the GC.
Right, I've heard this story before but has anyone actually tried
using D without the GC? I'm genuinely curiou
There we go, into the bee's nest. I'll just keep quiet.
On Sat, 03 Dec 2011 12:43:08 -0500, Marco Leise wrote:
Am 03.12.2011, 10:01 Uhr, schrieb Benjamin Thaut
:
Thanks, That doesn't sound to bad. If I manage to get a non leaking non
gc version of d-runtime working would there be any interest in that?
Kind Regards
Benjamin Thaut
That would
Ok, this is probably a silly question but why are the array appending
operations dependent on the GC. Why cant you allocate from a fixed pool?
or can you it just requires writing your own malloc/free implementation?
On 12/5/2011 5:46 AM, Steven Schveighoffer wrote:
On Sat, 03 Dec 2011 12:43:08
On 12/5/11 2:46 PM, Steven Schveighoffer wrote:
But what's difficult is finding leaks which don't have any anchor to
search for. For example, how do you search for code that allocates an
array and *doesn't* deallocate it?
By using a decent memory debugger/profiler like Valgrind?
David
Steven Schveighoffer wrote:
>On Sat, 03 Dec 2011 12:43:08 -0500, Marco Leise
>wrote:
>
>> Am 03.12.2011, 10:01 Uhr, schrieb Benjamin Thaut
>> :
>>
>>> Thanks, That doesn't sound to bad. If I manage to get a non leaking
>>> non gc version of d-runtime working would there be any interest in
>>> th
On Mon, 05 Dec 2011 11:34:18 -0500, Hans Uhlig
wrote:
Ok, this is probably a silly question but why are the array appending
operations dependent on the GC. Why cant you allocate from a fixed pool?
or can you it just requires writing your own malloc/free implementation?
This might help:
On 2011-12-05 17:56, Johannes Pfau wrote:
I'd say don't replace the GC with a simple malloc/free stub, remove it
completely. Add a switch to dmd (-nogc) which disables all features
which need the gc (especially 'new', array appending, ...). This will
break a lot of code, but you won't have silent
On Sat, 03 Dec 2011 19:05:02 +0100, Andrej Mitrovic
wrote:
+1 on interest on having this. Back when I was attempting to port VST
to D I got asked by a Steinberg dev how I can guarantee that D plugins
will work. But I couldn't guarantee it, if a GC collection were to run
the plugin would freez
On 04.12.2011 21:04, Walter Bright wrote:
You're right, except for one point. If we ever do a moving GC, then the
GC has to either know about all the pointers (so it can modify them) or
the pointers must be 'pinned' (the pointed to object cannot be moved).
The way to 'pin' an object in D is to h
On 12/5/2011 11:52 AM, Norbert Nemec wrote:
On 04.12.2011 21:04, Walter Bright wrote:
You're right, except for one point. If we ever do a moving GC, then the
GC has to either know about all the pointers (so it can modify them) or
the pointers must be 'pinned' (the pointed to object cannot be mov
> Right - thanks for the hint!
>
> That would leave the following rules for real-time audio code in D:
>
> [snip]
What's about message passing? Is message passing hard real time ready?
On 05.12.2011 21:40, Tobias Pankrath wrote:
Right - thanks for the hint!
That would leave the following rules for real-time audio code in D:
[snip]
What's about message passing? Is message passing hard real time ready?
The issue actually came up for me a few weeks ago.
In principle, all yo
Le 05/12/2011 14:46, Steven Schveighoffer a écrit :
> On Sat, 03 Dec 2011 12:43:08 -0500, Marco Leise wrote:
>
>> Am 03.12.2011, 10:01 Uhr, schrieb Benjamin Thaut
>> :
>>
>>> Thanks, That doesn't sound to bad. If I manage to get a non leaking
>>> non gc version of d-runtime working would there be
No. Message-passing allocates a block of memory to transport the message. Even
with a free-list there may be an occasional allocation. I could look into using
an array instead of a linked list, but that would mean memmoves. In receive.
Sent from my iPhone
On Dec 5, 2011, at 12:40 PM, Tobias Pa
On 12/6/11 8:11 PM, Sean Kelly wrote:
No. Message-passing allocates a block of memory to transport the message. Even
with a free-list there may be an occasional allocation. I could look into using
an array instead of a linked list, but that would mean memmoves. In receive.
Sent from my iPhone
On 12/5/2011 3:22 PM, Norbert Nemec wrote:
On 05.12.2011 21:40, Tobias Pankrath wrote:
Right - thanks for the hint!
That would leave the following rules for real-time audio code in D:
[snip]
What's about message passing? Is message passing hard real time ready?
The issue actually came up f
On 07.12.2011 18:14, Sean Cavanaugh wrote:
On 12/5/2011 3:22 PM, Norbert Nemec wrote:
On 05.12.2011 21:40, Tobias Pankrath wrote:
Right - thanks for the hint!
That would leave the following rules for real-time audio code in D:
[snip]
What's about message passing? Is message passing hard rea
On Dec 9, 2011, at 12:04 AM, Norbert Nemec wrote:
> On 07.12.2011 18:14, Sean Cavanaugh wrote:
>>
>>
>> In windows land you would use MsgWaitForMultipleObject on the sleepy
>> thread and wake it up with a kernel object of some kind (an Event most
>> likely)
>
> How do you generate the kernel ob
36 matches
Mail list logo
