Hi Kristis,

Thanks for the updated version, I have installed and tested it on my
Windows environment and it seems for work well - thanks.
 
> 2) I can't figure out why we are getting a corrupted response from
> $socket->peeraddr():
> 
> http://bugzilla.mkgnu.net/show_bug.cgi?id=264#c30
> http://bugzilla.mkgnu.net/show_bug.cgi?id=264#c33

I am seeing this as well:

Mon Feb 19 10:02:13 2007 10.100.83.101:3745 Processing connection from 
dSe

So and my host isn't on a machine called dSe :-( (And we seem to have
picked up a carriage return).  The IP address is the IP address where
the Daemon is running.

> 3) I did not move the $bugtracker variable so that it isn't global. 
> 
> First, invoking get_bugtracker() when a connection is 
> processed is not desirable, since this would let a user 
> believe that the daemon started correctly and be faced with a 
> problem later on when committing (e.g. the version of the 
> bugtracker is not supported).

I understand this, and see why you want to do this stuff up-front.

> Second, I don't understand why this would give us "threading 
> issues". It seems that all thread data (even global data) 
> would be locally copied:
> 
> http://perldoc.perl.org/perlthrtut.html#Shared-And-Unshared-Data


This is where my lack of Perl knowledge is showing (This is the first
real work that I have done in Perl).  I was comparing it to C++, Java
threading issues - so you are correct there isn't a problem.

You may want to remove the function get_new_bugtracker() from the
Daemon.pm file as it's no-longer used.

> Does this mean that $request could have remained a global 
> variable too ?
> Just want to make sure I understand what's going on.

In theory I suppose so, however I think that it is better to keep it
local.  I can understand the bugtracker being global as it is a
connection to a single bugtracker system.  However the request is just
one request, and is unique from the other requests.  I also think it
makes it a lot easier to understand as you can see where the request
actually originates in the code.


> 4) What's the harm if we do write a pid file for Windows ?

I don't see any harm in it, however I made it conditional just in case,
as recent comments on the mailing-list mentioned doing some checking to
see if it existed before allowing the Daemon to start. (A UNIX issue, so
I didn't want any chance of it breaking Windows).

> I'll be emailing you a private release for Windows. Let me 
> know how it works for you. Also, did threading really fix the 
> crash problem you've been experiencing ? Or do you need more 
> time to test ? I'm curious -- we haven't really figured out 
> the reason we are crashing.

I believe the changes that we have made DO fix the multi-message problem
that I was seeing.  I used to reliably be able to recreate the problem,
and since the changes can not reproduce it.

As things stand the version that you E-mailed me (0-19-8) is the version
we will go live with. (Assuming we go live before you release another
one :-)).

Thanks

Rob
_______________________________________________
scmbug-users mailing list
[email protected]
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users

Reply via email to