View previous topic :: View next topic |
Author |
Message |
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Tue Jul 13, 2004 11:09 pm Post subject: Mango Beta 9.1 ready for download |
|
|
... and you can get it here: http://svn.dsource.org/svn/projects/mango/downloads/
As usual, the changes are noted in the readme.txt file. Here's some highlights:
- a few bugs fixed
- mango.cluster has filled out considerably, attributable to old age. It needs a howto document though
- ICacheEntry had to change its name to IPayload to play nicely with mango.cluster (hope that's not a major inconvenience)
- Kris |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Wed Jul 14, 2004 1:23 am Post subject: |
|
|
I downloaded the update from svn. Here's an odd error. Cluster.d uses msleep(). Oddly, Linux doesn't appear to have this C function although phobos defines it in std.c.time for all platforms. Apparantly Linux only has usleep() (microsecond based), so I guess that will have to used instead of msleep in Cluster.d.
This is a phobos error then.
I assume usleep(500000) should replace msleep(500) on Linux then. |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Wed Jul 14, 2004 2:48 am Post subject: |
|
|
Thanks John. I'll change it to usleep (500_000) ...
Other than that, are there any compile problems? |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Wed Jul 14, 2004 11:31 am Post subject: |
|
|
You're not going to like this, Kris. It segfaults in the same spot as before when testing testMulticast()... and that's even though it doesn't have the invalid "break."
And it appears to be the same gc corruption problem (mark).
Alas, the pain is not complete... |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Wed Jul 14, 2004 12:30 pm Post subject: |
|
|
JJR wrote: | You're not going to like this, Kris. It segfaults in the same spot as before when testing testMulticast()... and that's even though it doesn't have the invalid "break."
And it appears to be the same gc corruption problem (mark).
Alas, the pain is not complete... |
<sigh>
Have you tried adding your printf() again to see how many times reader.read() is invoked? And then, how about changing the "lives = 0;" to a plain old "return 0;"? What a hassle. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Wed Jul 14, 2004 1:32 pm Post subject: |
|
|
It seems that the (quit || Socket.isCancelled()) branch is never being taken; therefore, lives is never set to 0. Kind of strange.
As a result, the while loop is iterating twice and getting hung up after the second reader.read(buffer);
Here's a sample of the output:
Code: | SocketListener.d: top of while() lives=3
SocketListener.d:before buffer.clear()
SocketListener.d:after buffer.clear()
SocketListener.d:before reader.read()
SocketListener.d: after reader.read()
listener received 1000 bytes
SocketListener.d:end of try{}
SocketListener.d: lives=3 <<-- at end of try
SocketListener.d: end of while()
SocketListener.d: top of while() lives=3
SocketListener.d: before buffer.clear()
SocketListener.d: after buffer.clear()
SocketListener.d: before reader.read()
37091 INFO mango.unittest - Done
Segmentation fault |
Maybe it's me, but I don't see program flow logic where quit would ever be set or Socket.cancelAll() would be called (other than an explicit call to the cancel() method in SocketListener. Is it in there somewhere? |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Wed Jul 14, 2004 1:44 pm Post subject: |
|
|
JJR wrote: | It seems that the (quit || Socket.isCancelled()) branch is never being taken; therefore, lives is never set to 0. Kind of strange.
As a result, the while loop is iterating twice and getting hung up after the second reader.read(buffer);
Here's a sample of the output:
Code: | SocketListener.d: top of while() lives=3
SocketListener.d:before buffer.clear()
SocketListener.d:after buffer.clear()
SocketListener.d:before reader.read()
SocketListener.d: after reader.read()
listener received 1000 bytes
SocketListener.d:end of try{}
SocketListener.d: lives=3 <<-- at end of try
SocketListener.d: end of while()
SocketListener.d: top of while() lives=3
SocketListener.d: before buffer.clear()
SocketListener.d: after buffer.clear()
SocketListener.d: before reader.read()
37091 INFO mango.unittest - Done
Segmentation fault |
Maybe it's me, but I don't see program flow logic where quit would ever be set or Socket.cancelAll() would be called (other than an explicit call to the cancel() method in SocketListener. Is it in there somewhere? |
The above looks correct to me John. it *should* loop back after the initial read(), but not after the read() is interrupted by program termination. If there's some additional output between "mango.unittest - Done" and the segmentation fault, that would be a different story.
Regarding program flow; Socket.cancelAll() is in the static destructor for the Socket.d module. The idea is that you (as a programmer) don't have to maintain a list of all the currently running listeners and explicitly cancel() each one after somehow detecting a program-exit condition. The static destructor should take care of it (and did the last time you tried this I believe). Perhaps it's worth placing a printf in the Socket.d static destructor again? |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Wed Jul 14, 2004 1:46 pm Post subject: |
|
|
Glad to see the log timestamp is looking more reasonable |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Wed Jul 14, 2004 2:06 pm Post subject: |
|
|
kris wrote: | The above looks correct to me John. it *should* loop back after the initial read(), but not after the read() is interrupted by program termination. If there's some additional output between "mango.unittest - Done" and the segmentation fault, that would be a different story. |
Ok, I'm beginning to see this a little more clearly...
kris wrote: | Regarding program flow; Socket.cancelAll() is in the static destructor for the Socket.d module. The idea is that you (as a programmer) don't have to maintain a list of all the currently running listeners and explicitly cancel() each one after somehow detecting a program-exit condition. The static destructor should take care of it (and did the last time you tried this I believe). Perhaps it's worth placing a printf in the Socket.d static destructor again? |
Oops... I forgot about the effects fo the static module destructor. Short memory.
I put the printf's in that destructor again... and it is getting called correctly. I guess the effects don't seem to be caught by the still-alive listener thread. How long does the "static bool cancelled" flag in the Socket class remain accessible after a module destructor has been called? Since static variables are much like gloabal variables, the gc should have no involvement with them, no? But at the same time, if the main program has ended, and the module Socket destructor has been called, how do you determine if the Socket.cancel variable is still valid anymore?
Excuse me if I'm posing any silly questions here.... |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Wed Jul 14, 2004 2:37 pm Post subject: |
|
|
So, where in the sequence does the static destructor get invoked? Is it after the "mango.unittest - Done" and before the segfault?
Good question about the lifespan of the static Socket.cancelled ... I had just assumed it was the equivalent of checking a global variable, but then the Socket.isCancelled() is a static method call on a module that should have gone through its static destructor already. I wonder if there's some bogosity in doing that?
To answer the question, I added a global-scope method isDone() along with a 'done' bool to Socket.d, where the latter is set by the destructor also. Now it looks just like a C method ... then checked the generated code to see if there was any difference in how the two methods (isDone & isCancelled) interact with their environment and how the caller invokes them. From that I can say that a static method residing within a class is treated (from an execution standpoint) exactly the same way as a global method is; there's no noticeable difference in this test. That does not mean it's the same under linux, but it's very likely to be the case.
Just to be sure we're not on another wild-goose chase, if you comment out the testMulticast() line
Code: | IListener s = new MyListener (ms, new Buffer (1500));
|
... then I assume there's no segfault right? |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Wed Jul 14, 2004 3:05 pm Post subject: |
|
|
kris wrote: | Just to be sure we're not on another wild-goose chase, if you comment out the testMulticast() line
Code: | IListener s = new MyListener (ms, new Buffer (1500));
|
... then I assume there's no segfault right? |
Correct. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Wed Jul 14, 2004 3:14 pm Post subject: |
|
|
I'm going to be away for several hours. I got called out to work.
Will check in to the forum when I get back.... |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Wed Jul 14, 2004 8:04 pm Post subject: |
|
|
... and my dsl modem apparently died right after my last post (this is dialup). Will get back online in a few days.
- Kris |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Thu Jul 15, 2004 3:43 pm Post subject: |
|
|
Ugh... my little callout to work turned into 16.8 hours of work straight! That's one of the longest jaunts I've done in awhile.
Kris, you're on a modem again? Ouch, how will you survive? I borrowed my folks dialup connection once while visiting them -- the speed (or lack thereof) was almost unbearable. I almost had to start playing the "Blue Danube" to get into the right mood!
Take away my DSL,and I'd probably start twitching from withdrawel. |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Thu Jul 15, 2004 4:37 pm Post subject: |
|
|
JJR wrote: | Ugh... my little callout to work turned into 16.8 hours of work straight! That's one of the longest jaunts I've done in awhile.
Kris, you're on a modem again? Ouch, how will you survive? I borrowed my folks dialup connection once while visiting them -- the speed (or lack thereof) was almost unbearable. I almost had to start playing the "Blue Danube" to get into the right mood!
Take away my DSL,and I'd probably start twitching from withdrawel. |
Know what you mean <twitch; judder>
That's a long day John! Especially when it's not in front of a monitor |
|
Back to top |
|
|
|