On Thursday, 23 September 2021 at 19:32:12 UTC, eugene wrote:
C (more elaborated) variant:
http://zed.karelia.ru/mmedia/bin/edsm-g2-rev-h.tar.gz
Sound, GUI? Easy, see
http://zed.karelia.ru/mmedia/bin/xjiss4.tar.gz
It's computer keyboard 'piano', based on the same engine.
As I've already
On Thursday, 23 September 2021 at 18:53:25 UTC, Steven
Schveighoffer wrote:
On 9/23/21 1:44 PM, eugene wrote:
Just a note: there is no 'signal handler' in the program.
SIGINT/SIGTERM are **blocked**, notifications (POLLIN) are
received via epoll_wait().
Oh interesting! I didn't read the code
On 9/23/21 1:44 PM, eugene wrote:
On Thursday, 23 September 2021 at 17:20:18 UTC, Steven Schveighoffer wrote:
So imagine the sequence:
With ease!
1. ctrl-c, signal handler triggers, shutting down the loop
Just a note: there is no 'signal handler' in the program.
SIGINT/SIGTERM are
On Thursday, 23 September 2021 at 18:43:36 UTC, Steven
Schveighoffer wrote:
With dmd -O -inline, there is a chance it will be collected.
Inlining is key here.
never mind, GC.addRoot() looks more trustworthy, anyway :)
On 9/23/21 2:18 PM, eugene wrote:
On Thursday, 23 September 2021 at 17:16:23 UTC, Steven Schveighoffer wrote:
On 9/23/21 12:58 PM, eugene wrote:
On Thursday, 23 September 2021 at 15:56:16 UTC, Steven Schveighoffer
wrote:
See more details:
On Thursday, 23 September 2021 at 17:16:23 UTC, Steven
Schveighoffer wrote:
On 9/23/21 12:58 PM, eugene wrote:
On Thursday, 23 September 2021 at 15:56:16 UTC, Steven
Schveighoffer wrote:
See more details:
https://docs.microsoft.com/en-us/dotnet/api/system.gc.keepalive?view=net-5.0#remarks
On Thursday, 23 September 2021 at 17:53:00 UTC, eugene wrote:
On Thursday, 23 September 2021 at 17:49:43 UTC, eugene wrote:
On Thursday, 23 September 2021 at 17:20:18 UTC, Steven
Schveighoffer wrote:
1. ctrl-c, signal handler triggers, shutting down the loop
2. main exits
3. GC finalizes all
On Thursday, 23 September 2021 at 17:49:43 UTC, eugene wrote:
On Thursday, 23 September 2021 at 17:20:18 UTC, Steven
Schveighoffer wrote:
1. ctrl-c, signal handler triggers, shutting down the loop
2. main exits
3. GC finalizes all objects, including the Stopper and it's
members
but both
On Thursday, 23 September 2021 at 17:20:18 UTC, Steven
Schveighoffer wrote:
1. ctrl-c, signal handler triggers, shutting down the loop
2. main exits
3. GC finalizes all objects, including the Stopper and it's
members
but both SIGINT and SIGTERM are still **blocked**,
they just will not reach
On Thursday, 23 September 2021 at 17:20:18 UTC, Steven
Schveighoffer wrote:
So imagine the sequence:
With ease!
1. ctrl-c, signal handler triggers, shutting down the loop
Just a note: there is no 'signal handler' in the program.
SIGINT/SIGTERM are **blocked**, notifications (POLLIN) are
On 9/23/21 12:53 PM, eugene wrote:
On Thursday, 23 September 2021 at 15:53:37 UTC, Steven Schveighoffer wrote:
Technically, they should live past the end of main, because it's still
possible to receive signals then.
No, as soon as an application get SIGTERM/SIGINT,
event queue is stopped and
On 9/23/21 12:58 PM, eugene wrote:
On Thursday, 23 September 2021 at 15:56:16 UTC, Steven Schveighoffer wrote:
See more details:
https://docs.microsoft.com/en-us/dotnet/api/system.gc.keepalive?view=net-5.0#remarks
"
This method references the obj parameter, making that object ineligible
On Thursday, 23 September 2021 at 15:56:16 UTC, Steven
Schveighoffer wrote:
See more details:
https://docs.microsoft.com/en-us/dotnet/api/system.gc.keepalive?view=net-5.0#remarks
"
This method references the obj parameter, making that object
ineligible for garbage collection from the start
On Thursday, 23 September 2021 at 15:53:37 UTC, Steven
Schveighoffer wrote:
Technically, they should live past the end of main, because
it's still possible to receive signals then.
No, as soon as an application get SIGTERM/SIGINT,
event queue is stopped and we do not need no
more notifications
On 9/23/21 9:18 AM, eugene wrote:
On Thursday, 23 September 2021 at 12:53:14 UTC, Steven Schveighoffer wrote:
We need to add a better way to do that (similar to C# KeepAlive).
Do you mean some function attribute?..
C# KeepAlive (and Go KeepAlive) are a mechanism to do exactly what you
On 9/23/21 10:55 AM, eugene wrote:
On Thursday, 23 September 2021 at 14:31:34 UTC, jfondren wrote:
Nice. I thought of GC.addRoot several times but I was distracted by
the general solution of using object lifetimes with it, so that a
struct's destructor would call GC.removeRoot. For your case
On Thursday, 23 September 2021 at 14:31:34 UTC, jfondren wrote:
Nice. I thought of GC.addRoot several times but I was
distracted by the general solution of using object lifetimes
with it, so that a struct's destructor would call
GC.removeRoot. For your case just pinning these and forgetting
On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote:
And the most strange thing is this - if using gdc with -Os
flag, the program behaves
exactly as when compiled with fresh dmd - destructors for sg0
and sg1 are called soon after program start.
Now I guess, gdc optimization by size
On Thursday, 23 September 2021 at 14:23:40 UTC, eugene wrote:
On Thursday, 23 September 2021 at 14:00:30 UTC, eugene wrote:
For the moment I am personally quite happy
```d
void main(string[] args) {
import core.memory : GC;
auto Main = new Main();
GC.addRoot(cast(void*)Main);
On Thursday, 23 September 2021 at 14:00:30 UTC, eugene wrote:
For the moment I am personally quite happy
```d
void main(string[] args) {
import core.memory : GC;
auto Main = new Main();
GC.addRoot(cast(void*)Main);
Main.run();
auto stopper = new Stopper();
On Thursday, 23 September 2021 at 13:30:42 UTC, eugene wrote:
So, in C it is MY (potentially wrong) code.
In D, it is NOT MY code, it is GC.
Actually in both cases it is MY+the compiler's code. A very
similar example from C-land (without my digging up the exact
details) is something like
On Thursday, 23 September 2021 at 12:53:14 UTC, Steven
Schveighoffer wrote:
With the caveat, of course, that the recommendation to "leave a
pointer on the stack" is not as easy to follow as one might
think with the optimizer fighting against that. We need to add
a better way to do that
On Thursday, 23 September 2021 at 13:05:07 UTC, Steven
Schveighoffer wrote:
UB in C leaves traps for the programmer, similar to this trap
you have found in the GC. Where code doesn't do what you are
expecting it to do.
There is a difference, though.
As I've already said,
GC is a sort of
On Thursday, 23 September 2021 at 12:53:14 UTC, Steven
Schveighoffer wrote:
Show me these rules!
They are here:
https://dlang.org/spec/interfaceToC.html#storage_allocation
With the caveat, of course, that the recommendation to "leave a
pointer on the stack" is not as easy to follow as one
On 9/23/21 8:10 AM, eugene wrote:
On Wednesday, 22 September 2021 at 18:38:34 UTC, Steven Schveighoffer
wrote:
I find it interesting how you blame yourself for C's idiosyncrasies
Me? Blaming *myself* for C 'idiosyncrasies'? :) Where?
"When my C program crashes, I'm 100% sure I made
On 9/23/21 3:27 AM, eugene wrote:
On Wednesday, 22 September 2021 at 18:38:34 UTC, Steven Schveighoffer
wrote:
Your experience is not typical though (clearly, as many of us
long-time D users had no idea why it was happening).
Oh, yeah - I have special trait of bumping against
various low
On Wednesday, 22 September 2021 at 18:38:34 UTC, Steven
Schveighoffer wrote:
I find it interesting how you blame yourself for C's
idiosyncrasies
Me? Blaming *myself* for C 'idiosyncrasies'? :) Where?
but not for D's ;)
I've been learning D for about 3 months only.
I would say C has far
On Wednesday, 22 September 2021 at 18:38:34 UTC, Steven
Schveighoffer wrote:
But realize that C has it's share of "shocks" as well
Any language is just an instrument,
most of the 'shocks' come not from
languages themselves, but from the
'enviromment', so to say.
An example that came to
On Wednesday, 22 September 2021 at 18:38:34 UTC, Steven
Schveighoffer wrote:
In terms of any kind of memory management, whether it be ARC,
manual, GC, or anything else, there will always be pitfalls.
It's just that you have to get used to the pitfalls and how to
avoid them.
100% agree.
I
On Wednesday, 22 September 2021 at 18:38:34 UTC, Steven
Schveighoffer wrote:
Your experience is not typical though (clearly, as many of us
long-time D users had no idea why it was happening).
Oh, yeah - I have special trait of bumping against
various low probability things :)
But for sure if
On 9/22/21 11:47 AM, eugene wrote:
On Wednesday, 22 September 2021 at 12:26:53 UTC, Steven Schveighoffer
wrote:
On 9/22/21 8:22 AM, eugene wrote:
And it follows that programming in GC-supporting languages
*may* be harder than in languages with manual memory
management, right?
I meant my this
On Wednesday, 22 September 2021 at 12:26:53 UTC, Steven
Schveighoffer wrote:
On 9/22/21 8:22 AM, eugene wrote:
And it follows that programming in GC-supporting languages
*may* be harder than in languages with manual memory
management, right?
I meant my this particular trouble...
I do not want
On 9/22/21 8:22 AM, eugene wrote:
On Wednesday, 22 September 2021 at 11:44:16 UTC, Steven Schveighoffer
wrote:
Once it's on the stack, the GC can see it for the full run of `main`.
This is why this case is different.
Note that Java is even more aggressive, and might *still* collect it,
On Wednesday, 22 September 2021 at 11:44:16 UTC, Steven
Schveighoffer wrote:
Once it's on the stack, the GC can see it for the full run of
`main`. This is why this case is different.
Note that Java is even more aggressive, and might *still*
collect it, because it could legitimately set
On Wednesday, 22 September 2021 at 11:44:16 UTC, Steven
Schveighoffer wrote:
Here is what is happening.
Many thanks for this so exhaustive explanation!
On 9/21/21 4:17 PM, eugene wrote:
On Tuesday, 21 September 2021 at 19:42:48 UTC, jfondren wrote:
On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote:
There's nothing special about sg0 and sg1, except that they're part of
Stopper. The Stopper in main() is collected before the end of
On Wednesday, 22 September 2021 at 10:05:05 UTC, jfondren wrote:
Nondeterminism in heap collection is a very common complaint,
It is another kind of nondeterminism that is usually complained
about
("*sometime* in the future GC will collect if it wants" or so)
but here we have data is that
On Wednesday, 22 September 2021 at 08:03:59 UTC, eugene wrote:
On Tuesday, 21 September 2021 at 20:28:33 UTC, jfondren wrote:
Everything is Ok now,
I don't think this is reliably OK. If you're not using Stopper
later in the function, and if there are no other references to
it, then the GC
On Tuesday, 21 September 2021 at 20:28:33 UTC, jfondren wrote:
Everything is Ok now,
I don't think this is reliably OK. If you're not using Stopper
later in the function, and if there are no other references to
it, then the GC can collect it. It just has no obligation to
collect it, so
On Tuesday, 21 September 2021 at 20:42:12 UTC, H. S. Teoh wrote:
A sufficiently optimizing compiler may determine that since
Main and stopper are independent, it is free to reorder the
code such that the two lifetimes are independent, and therefore
end up with the same situation as the first
On Tuesday, 21 September 2021 at 20:47:41 UTC, H. S. Teoh wrote:
Век живи - век учись. А дураком помрёшь.
:)
"Век живи - век учись, всё равно дураком помрёшь."
is correct version. :)
On Tuesday, 21 September 2021 at 20:47:41 UTC, H. S. Teoh wrote:
And since stopper isn't used anymore after declaration, an
optimizing compiler is free to assume that it's not needed
afterwards, so it's not obligated to keep the reference alive
until the end of the function.
It was not
On Tue, Sep 21, 2021 at 08:36:49PM +, eugene via Digitalmars-d-learn wrote:
> On Tuesday, 21 September 2021 at 20:17:15 UTC, eugene wrote:
>
> > Now, change operation order in the main like this:
>
> Actually, all proposed 'fixes'
>
> - use stopper somehow in the end
On Tue, Sep 21, 2021 at 08:17:15PM +, eugene via Digitalmars-d-learn wrote:
[...]
> ```d
> void main(string[] args) {
>
> auto Main = new Main();
> Main.run();
>
> auto stopper = new Stopper();
> stopper.run();
> ```
[...]
> ```d
> void main(string[] args) {
>
> auto
On Tuesday, 21 September 2021 at 20:17:15 UTC, eugene wrote:
Now, change operation order in the main like this:
Actually, all proposed 'fixes'
- use stopper somehow in the end (writeln(stopper.sg0.number))
- change operation order
- etc
are strange. I mean it's strange (for me) that these
On Tuesday, 21 September 2021 at 20:17:15 UTC, eugene wrote:
Now, change operation order in the main like this:
```d
void main(string[] args) {
auto Main = new Main();
auto stopper = new Stopper();
Main.run();
stopper.run();
```
```
d-lang/edsm-in-d-simple-example-2 $ ./test
On Tue, Sep 21, 2021 at 07:42:48PM +, jfondren via Digitalmars-d-learn
wrote:
> On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote:
> > I do not understand at all why GC considers those sg0 and sg1 as
> > unreferenced.
> > And why old gdc (without -Os) and old ldc do not.
>
>
On Tuesday, 21 September 2021 at 19:42:48 UTC, jfondren wrote:
On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote:
There's nothing special about sg0 and sg1, except that they're
part of Stopper. The Stopper in main() is collected before the
end of main() because it's not used later in
On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote:
I do not understand at all why GC considers those sg0 and sg1
as unreferenced.
And why old gdc (without -Os) and old ldc do not.
Conclusion:
There's nothing special about sg0 and sg1, except that they're
part of Stopper. The
On Sunday, 19 September 2021 at 21:10:16 UTC, eugene wrote:
I rearranged the code of main() like this:
Similar rearrangement fixed the echo-client as well.
(I moved creation of Stopper to the very beginning of main())
On Sunday, 19 September 2021 at 20:12:45 UTC, eugene wrote:
On Monday, 13 September 2021 at 17:54:43 UTC, eugene wrote:
full src is here
http://zed.karelia.ru/0/e/edsm-in-d-2021-09-10.tar.gz
I've also made two simple examples, just in case
-
On Sunday, 19 September 2021 at 16:27:55 UTC, jfondren wrote:
This is also a sufficient patch to prevent the segfault:
```
diff --git a/echo_client.d b/echo_client.d
index 1f8270e..0b968a8 100644
--- a/echo_client.d
+++ b/echo_client.d
@@ -39,4 +39,6 @@ void main(string[] args) {
auto md =
On Sunday, 19 September 2021 at 16:27:55 UTC, jfondren wrote:
This is a sufficient patch to prevent the segfault:
```
diff --git a/echo_client.d b/echo_client.d
index 1f8270e..5ec41df 100644
--- a/echo_client.d
+++ b/echo_client.d
@@ -32,7 +32,7 @@ void main(string[] args) {
sm.run();
On Monday, 13 September 2021 at 17:54:43 UTC, eugene wrote:
full src is here
http://zed.karelia.ru/0/e/edsm-in-d-2021-09-10.tar.gz
I've also made two simple examples, just in case
- http://zed.karelia.ru/0/e/edsm-in-d-simple-example-1.tar.gz
Program does nothing, just waits for ^c, does not
On Sunday, 19 September 2021 at 16:27:55 UTC, jfondren wrote:
So the problem here is that ctrl-C causes that message to come
but Stopper's been collected and that address contains garbage.
This is exactly what I was trying to say...
Thanx a lot for your in-depth investigation of the trouble!
On Sunday, 19 September 2021 at 08:51:31 UTC, eugene wrote:
reference-containing struct that vanishes on the return of
your corresponding function
I do not think it's a problem, otherwise **both programs would
not work at all**.
The GC doesn't reliably punish objects living past there not
On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote:
The instance of Stopper is created in the scope of main():
```d
void main(string[] args) {
auto stopper = new Stopper();
stopper.run();
```
Look...
I have added stopper into an array...
```d
Stopper[] stoppers;
auto
On Saturday, 18 September 2021 at 09:54:05 UTC, jfondren wrote:
On Saturday, 18 September 2021 at 09:39:24 UTC, eugene wrote:
The definition of this struct was taken from
/usr/include/dmd/druntime/import/core/sys/linux/epoll.d
...
If the reason for crash was in EpollEvent alignment,
programs
On Wednesday, 15 September 2021 at 23:07:45 UTC, jfondren wrote:
Yep. This patch is sufficient to prevent the segfault:
Your idea (hold references to all event sources somewhere) is
quite clear,
but it confuses me a bit, since
1) there **are** references to all event sources **already**,
reference-containing struct that vanishes on the return of your
corresponding function
I do not think it's a problem, otherwise **both programs would
not work at all**.
However, echo-server works without any surprises;
echo-client also works, except that EventSources
pointed by sg0 and sg1
On Saturday, 18 September 2021 at 09:39:24 UTC, eugene wrote:
The definition of this struct was taken from
/usr/include/dmd/druntime/import/core/sys/linux/epoll.d
...
If the reason for crash was in EpollEvent alignment,
programs would segfaults always very soon after start,
just right after
On Tuesday, 14 September 2021 at 20:59:14 UTC, Ali Çehreli wrote:
On 9/14/21 9:56 AM, eugene wrote:
> On Tuesday, 14 September 2021 at 16:43:50 UTC, jfondren wrote:
>> The misaligned pointer and the
>> reference-containing struct that vanishes on the return of
your
>> corresponding function
On Tuesday, 14 September 2021 at 20:59:14 UTC, Ali Çehreli wrote:
On 9/14/21 9:56 AM, eugene wrote:
> On Tuesday, 14 September 2021 at 16:43:50 UTC, jfondren wrote:
>> The misaligned pointer and the
>> reference-containing struct that vanishes on the return of
your
>> corresponding function
On 9/14/21 9:56 AM, eugene wrote:
> On Tuesday, 14 September 2021 at 16:43:50 UTC, jfondren wrote:
>> The misaligned pointer and the
>> reference-containing struct that vanishes on the return of your
>> corresponding function are both problems for this.
>
> where did you find 'misaligned
On Tuesday, 14 September 2021 at 18:33:33 UTC, Steven
Schveighoffer wrote:
People are trying to help you here.
Then, answer the questions.
Why those sg0 and sg1 are 'collected'
by this so f... antstic GC?
On 9/14/21 2:05 PM, eugene wrote:
On Tuesday, 14 September 2021 at 17:02:32 UTC, jfondren wrote:
It doesn't seem like communication between us is possible
and you are wrong, as usual ,)
in the "a five-pound phone won't sell" way.
I am not a 'selling boy'
My suggestion remains: try
On Tuesday, 14 September 2021 at 17:02:32 UTC, jfondren wrote:
It doesn't seem like communication between us is possible
and you are wrong, as usual ,)
in the "a five-pound phone won't sell" way.
I am not a 'selling boy'
My suggestion remains: try troubleshooting by making your
program
On Tuesday, 14 September 2021 at 16:56:52 UTC, eugene wrote:
On Tuesday, 14 September 2021 at 16:43:50 UTC, jfondren wrote:
GC needs to be able to stop your program
nice fantasies...
and find all of the live objects in it. The misaligned pointer
and the reference-containing struct that
On Tuesday, 14 September 2021 at 16:43:50 UTC, jfondren wrote:
GC needs to be able to stop your program
nice fantasies...
and find all of the live objects in it. The misaligned pointer
and the reference-containing struct that vanishes on the return
of your corresponding function are both
On Tuesday, 14 September 2021 at 16:15:20 UTC, eugene wrote:
On Tuesday, 14 September 2021 at 16:07:00 UTC, jfondren wrote:
No. And when was the first one?
here:
On Monday, 13 September 2021 at 18:45:22 UTC, jfondren wrote:
auto p = cast(EpollEvent*) pureMalloc(EpollEvent.sizeof);
What?
On Tuesday, 14 September 2021 at 16:07:00 UTC, jfondren wrote:
No. And when was the first one?
here:
On Monday, 13 September 2021 at 18:45:22 UTC, jfondren wrote:
auto p = cast(EpollEvent*) pureMalloc(EpollEvent.sizeof);
What? Allocate struct epoll_event on the heap?
It is a feeble joke
On Tuesday, 14 September 2021 at 15:37:27 UTC, eugene wrote:
On Tuesday, 14 September 2021 at 14:56:00 UTC, jfondren wrote:
You could fix this by having a 128-bit struct and passing C an
index into it
It is another "not so funny joke", isn't it?
No. And when was the first one?
```d
align
On 9/14/21 10:56 AM, jfondren wrote:
On Tuesday, 14 September 2021 at 14:40:55 UTC, eugene wrote:
On Tuesday, 14 September 2021 at 12:09:03 UTC, Steven Schveighoffer
wrote:
This project is too big and complex
Really, "too big and complex"?
It's as simple as a tabouret :)
It's just a
On Tuesday, 14 September 2021 at 14:56:00 UTC, jfondren wrote:
You could fix this by having a 128-bit struct and passing C an
index into it
It is another "not so funny joke", isn't it?
Look
```c
typedef union epoll_data {
void *ptr;
int fd;
uint32_t u32;
On Tuesday, 14 September 2021 at 12:09:03 UTC, Steven
Schveighoffer wrote:
This project is too big and complex for me to diagnose by just
reading, it would take some effort
take a look at
On Tuesday, 14 September 2021 at 14:40:55 UTC, eugene wrote:
On Tuesday, 14 September 2021 at 12:09:03 UTC, Steven
Schveighoffer wrote:
This project is too big and complex
Really, "too big and complex"?
It's as simple as a tabouret :)
It's just a toy/hobby 'project'.
A 5-pound phone isn't
On Tuesday, 14 September 2021 at 12:09:03 UTC, Steven
Schveighoffer wrote:
This project is too big and complex
Really, "too big and complex"?
It's as simple as a tabouret :)
It's just a toy/hobby 'project'.
On Tuesday, 14 September 2021 at 12:52:44 UTC, Steven
Schveighoffer wrote:
But I agree that a superficial reading of your code seems like
it ought to not be collected, and that problem is also worth
figuring out. I have high confidence that it's probably not a
design flaw in the GC, but rather
On Tuesday, 14 September 2021 at 12:53:27 UTC, Adam D Ruppe wrote:
I had a problem just like this before because I was sending
objects through the pipe. And while they were in the pipe -
```rust
pub fn msg(, code: u32) {
let ptr: *const u32 =
let n = unsafe {
On Tuesday, 14 September 2021 at 12:53:27 UTC, Adam D Ruppe wrote:
I had a problem just like this before because I was sending
objects through the pipe.
This reminds my (not very successfull) attempts to implement the
idea in Rust:
```rust
pub struct Edsm {
name: String,
pub
On Tuesday, 14 September 2021 at 12:42:51 UTC, eugene wrote:
I understand your idea, but even if this will help, the question
remains - why that particular object is so special for GC.
I had a problem just like this before because I was sending
objects through the pipe. And while they were in
On 9/14/21 8:42 AM, eugene wrote:
On Tuesday, 14 September 2021 at 12:09:03 UTC, Steven Schveighoffer wrote:
I still recommend pinning the object when adding the epoll event and
seeing if that helps.
I understand your idea, but even if this will help, the question
remains - why that
On Tuesday, 14 September 2021 at 12:13:15 UTC, Steven
Schveighoffer wrote:
On 9/14/21 7:31 AM, eugene wrote:
On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote:
EventSource s = events[k].es;
ulong ecode = s.eventCode(events[k].event_mask);
// < SIGSEGV
On Tuesday, 14 September 2021 at 12:09:03 UTC, Steven
Schveighoffer wrote:
Though as I have learned helping C converts before, most of the
time things like this have to do with forgetting to store a GC
reference somewhere.
Yeah, in my first version I had
```d
foreach (k; 0 ..
On 9/14/21 7:31 AM, eugene wrote:
On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote:
Then after pressing ^C (SIGINT) the program gets SIGSEGV, since
references to sg0 and sg1 are no longer valid (they are "sitting" in
epoll_event structure).
... forget to mention, crashes here:
On 9/14/21 1:49 AM, Tejas wrote:
On Monday, 13 September 2021 at 18:42:47 UTC, Steven Schveighoffer wrote:
On 9/13/21 1:54 PM, eugene wrote:
[...]
The GC only scans things that it knows about.
Inside your EventQueue you have this code:
[...]
Umm is it okay that he declared variables
On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote:
Then after pressing ^C (SIGINT) the program gets SIGSEGV, since
references to sg0 and sg1 are no longer valid (they are
"sitting" in epoll_event structure).
... forget to mention, crashes here:
```d
bool wait() {
const
On Monday, 13 September 2021 at 18:45:22 UTC, jfondren wrote:
```d
auto p = cast(EpollEvent*)
pureMalloc(EpollEvent.sizeof);
```
What? Allocate struct epoll_event on the heap?
It is a feeble joke ;)
```c
static int ecap__add(int fd, void *dptr)
{
struct epoll_event waitfor =
On Tuesday, 14 September 2021 at 05:49:58 UTC, Tejas wrote:
Umm is it okay that he declared variables `init` and `idle` of
type `Stage` inside the constructor?
States of a machine are in associative array.
All other machines create their states in constructor,
local variables are for using
On Monday, 13 September 2021 at 18:42:47 UTC, Steven
Schveighoffer wrote:
On 9/13/21 1:54 PM, eugene wrote:
[...]
The GC only scans things that it knows about.
Inside your EventQueue you have this code:
[...]
Umm is it okay that he declared variables `init` and `idle` of
type `Stage`
On Monday, 13 September 2021 at 18:45:22 UTC, jfondren wrote:
Instead of using a temporary EpollEvent array in
EventQueue.wait, you could make the array an instance variable
and have registerEventSource populate it directly
Actually, initial version of all that was using array,
allocated in
On Monday, 13 September 2021 at 18:42:47 UTC, Steven
Schveighoffer wrote:
And you are registering your signals using the `+=` operator.
That was a sort of exercise with operator overloading.
Now, with your stopper code that you showed, it looks like you
are storing the reference to stopper
On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote:
Then after pressing ^C (SIGINT) the program gets SIGSEGV, since
references to sg0 and sg1 are no longer valid (they are
"sitting" in epoll_event structure).
engine/ecap.d(54): Error: field `EpollEvent.es` cannot assign to
misaligned
On 9/13/21 1:54 PM, eugene wrote:
On Monday, 13 September 2021 at 17:40:41 UTC, user1234 wrote:
The problems seems to lies in `newSignal()` which "would" not allocate
using the GC.
final Signal newSignal(int signum) {
Signal sg = new Signal(signum);
sg.owner = this;
On Monday, 13 September 2021 at 17:56:34 UTC, user1234 wrote:
thx, so the problem is not what I suspected to be (mixed
gc-managed and manually managed memory). sorrry...
I am actually C coder and do not have much experience
with GC languages, so I did not even attempt to
try use D without GC
On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote:
And the most strange thing is this
It is echo-server/echo-client pair.
And it is echo-client that crashes upon SIGINT.
echo-server contains very similar code
class Listener : StageMachine {
enum ulong M0_WORK = 0;
enum
On Monday, 13 September 2021 at 17:54:43 UTC, eugene wrote:
On Monday, 13 September 2021 at 17:40:41 UTC, user1234 wrote:
The problems seems to lies in `newSignal()` which "would" not
allocate using the GC.
final Signal newSignal(int signum) {
Signal sg = new Signal(signum);
On Monday, 13 September 2021 at 17:40:41 UTC, user1234 wrote:
The problems seems to lies in `newSignal()` which "would" not
allocate using the GC.
final Signal newSignal(int signum) {
Signal sg = new Signal(signum);
sg.owner = this;
sg.number = sg_number++;
On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote:
[...]
At first glance and given the fact that some code necessary to
diagnose the problem accurately is missing:
`new Stopper` allocates using the GC. it's then a "GC range",
it's content will be scanned and handled by the GC,
On Monday, 13 September 2021 at 17:40:41 UTC, user1234 wrote:
On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote:
[...]
At first glance and given the fact that some code necessary to
diagnose the problem accurately is missing:
`new Stopper` allocates using the GC. it's then a "GC
100 matches
Mail list logo
