Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.misc > #1502
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Newsgroups | comp.lang.misc, comp.lang.perl.misc |
| Subject | Re: should we Go now? |
| Date | 2013-02-25 17:54 +0000 |
| Message-ID | <87r4k4mg8o.fsf@sapphire.mobileactivedefense.com> (permalink) |
| References | <87hal29eeb.fsf@violet.siamics.net> <874nh1abn5.fsf@violet.siamics.net> <24eqv9-9mq.ln1@anubis.morrow.me.uk> <874nh08qpb.fsf@violet.siamics.net> <hicsv9-8lm1.ln1@anubis.morrow.me.uk> |
Cross-posted to 2 groups.
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Ivan Shmakov <oneingray@gmail.com>:
>> >>>>> Ben Morrow <ben@morrow.me.uk> writes:
>> >>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>>
>> >> Doesn't seem to be all that applicable to Go. Consider that:
>>
>> >> * Perl uses GC;
>>
>> > Perl uses refcounting. One of Perl's flaws is that it doesn't use
>> > proper GC.
>>
>> I know about the deficiencies of refcounting. However, it was
>> my understanding that it works quite well for Perl in practice.
>
> Yes and no. It works well in simple situations, and has the advantage of
> providing prompt destruction (see below), but as soon as a cyclic data
> structure is created the programmer has to be very careful to use
> weakrefs in all the right places, or the structure will never be
> collected.
'Cyclic data structures' are a relative fringe case and the advantage
that code like this doesn't have to be written in Perl:
public ImportInformationDTO importUsers(long domainId)
throws LoginException, NamingException, IOException {
ImportInformationDTO dto;
if (!trylockADImport(domainId)) {
log.warn("AD import for #0 already running", domainId);
return null;
}
try {
dto = doImportUsers(domainId);
} finally {
unlockADImport(domainId);
}
return dto;
}
by far outweighs the 'inconvenience' of having to use weak
references: This whole method has no other purpose than work around
the deficiencies of the Java garbage collector and if something like
this isn't meticolously distributed throughout a possibly 'large' body
of Java code (48,585 LOC in this case), resource leaks or resource
'hogging' will occur and this has caused numerous user-visible
problems for the people using this code (most often because the JVM
process ran out of file descriptors but it also ran out of memory(!),
out of database sessions and generally 'out of' whatever the tracing
collector cannot manage at all or cannot manage well enough to work
reliably in practice).
Back to comp.lang.misc | Previous | Next — Previous in thread | Next in thread | Find similar
should we Go now? Ivan Shmakov <oneingray@gmail.com> - 2013-02-24 10:47 +0000
Re: should we Go now? Ben Morrow <ben@morrow.me.uk> - 2013-02-24 13:40 +0000
Re: should we Go now? Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-02-24 16:37 +0000
Re: should we Go now? Ivan Shmakov <oneingray@gmail.com> - 2013-02-24 17:02 +0000
Re: should we Go now? Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-02-24 19:38 +0000
Re: should we Go now? Nils M Holm <news2009@t3x.org> - 2013-02-25 07:23 +0000
Re: should we Go now? Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-02-25 17:30 +0000
Re: should we Go now? Ben Morrow <ben@morrow.me.uk> - 2013-02-24 21:42 +0000
Re: should we Go now? Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-02-24 22:26 +0000
Re: should we Go now? Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-02-25 01:04 +0000
Re: should we Go now? Ivan Shmakov <oneingray@gmail.com> - 2013-02-25 13:32 +0000
Re: should we Go now? Ben Morrow <ben@morrow.me.uk> - 2013-02-25 15:28 +0000
Re: should we Go now? Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-02-25 17:54 +0000
Re: should we Go now? "BartC" <bc@freeuk.com> - 2013-02-25 01:29 +0000
Re: should we Go now? Ivan Shmakov <oneingray@gmail.com> - 2013-02-25 13:12 +0000
Re: should we Go now? Ivan Shmakov <oneingray@gmail.com> - 2013-02-24 17:04 +0000
Re: should we Go now? Bjoern Hoehrmann <bjoern@hoehrmann.de> - 2013-02-24 18:24 +0100
Re: should we Go now? Keith Thompson <kst-u@mib.org> - 2013-02-25 17:01 -0800
csiph-web