<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Recent posts to news</title><link>https://sourceforge.net/p/dcprod/news/</link><description>Recent posts to news</description><atom:link href="https://sourceforge.net/p/dcprod/news/feed.rss" rel="self"/><language>en</language><lastBuildDate>Fri, 14 Nov 2003 10:10:42 -0000</lastBuildDate><atom:link href="https://sourceforge.net/p/dcprod/news/feed.rss" rel="self" type="application/rss+xml"/><item><title>No more</title><link>https://sourceforge.net/p/dcprod/news/2003/11/no-more/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;Just to tell you, I will not do anything more on dcpro. I have not given up my DC aspirations, but I have decided to rewrite it from scratch. Once I get a complete system, search for Dolda Connect instead.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Fredrik Tolf</dc:creator><pubDate>Fri, 14 Nov 2003 10:10:42 -0000</pubDate><guid>https://sourceforge.net50196d2de56187084fdc03e0288f1f26f9258678</guid></item><item><title>Zombie processes, part 2</title><link>https://sourceforge.net/p/dcprod/news/2003/02/zombie-processes-part-2/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;I compensated for the CLONE_THREAD flaw in linuxthreads, so the issue with zombie filters seems to be solved now. The new release is available as dcprod 0.2-2.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Fredrik Tolf</dc:creator><pubDate>Mon, 17 Feb 2003 00:17:28 -0000</pubDate><guid>https://sourceforge.netb67138f09cdbea360f6033ea23f4a5d33946e13c</guid></item><item><title>Zombie processes</title><link>https://sourceforge.net/p/dcprod/news/2003/02/zombie-processes/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;I finally discovered why dcprod fails to wait for the filter processes. I suspected from the beginning that it was a flaw in the LinuxThreads implementation, but I thought it was that the signal handlers weren't correctly cloned. When I looked deeper, it turned out that LinuxThreads puts the cloned processes in different thread groups, even though Linux has had support for thread groups since the release of 2.4.&lt;br /&gt;
I was going to recommend everyone to upgrade their glibc, but then I found that not even the latest CVS version uses thread groups correctly.&lt;br /&gt;
I have begun writing a compensation for this issue in dcprod, so that the filter are both forked and waited for in the same thread, and hopefully I'll be done later tonight.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Fredrik Tolf</dc:creator><pubDate>Sun, 16 Feb 2003 22:04:54 -0000</pubDate><guid>https://sourceforge.netc9956547ad7982531075b9194fbfd05548f74edb</guid></item><item><title>dcprod GUI released</title><link>https://sourceforge.net/p/dcprod/news/2003/02/dcprod-gui-released/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;I've released a GUI in the dcpro (as opposed to dcprod) package. It runs with gtk+-1.2. Much is to be changed with this GUI. I will remake the make process, too. The current release is truly an alpha release, but it's far better than nothing.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Fredrik Tolf</dc:creator><pubDate>Thu, 13 Feb 2003 16:34:18 -0000</pubDate><guid>https://sourceforge.net535a98a1c45f9288864711468d4bbcc12e8c5e3e</guid></item><item><title>dcprod finally stable?</title><link>https://sourceforge.net/p/dcprod/news/2003/02/dcprod-finally-stable/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;I finally took my time to add list locking for interfaces and transfers. It seems to have paid off, though, becuase I'm not getting any of these strange, register changing crashes anymore. I've fixed some deadlocks, but some may be left.&lt;br /&gt;
The current bugs are more of the resource-devouring kind. For example, zombie filters aren't waited for, and there still seems to be a slight memory leak.&lt;br /&gt;
It seems stable enough to warrant a minor version number change, though.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Fredrik Tolf</dc:creator><pubDate>Thu, 13 Feb 2003 16:07:00 -0000</pubDate><guid>https://sourceforge.netf768d4ff0728c87aea82bba5d937ab47bff8648e</guid></item><item><title>New release</title><link>https://sourceforge.net/p/dcprod/news/2002/11/new-release/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;I released 0.1-9 today, in which I fixed som emore bugs, most significantly of which that I made interface fd:s nonblocking, something that used to block threads arbitrarily when connected to laggy hubs.&lt;br /&gt;
I've also added virtual file support for the share, which I plan to use for the file list one day. Unfortunately, the crappy DC protocol imposes some limitations on this, but it might still be usable for some purposes.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Fredrik Tolf</dc:creator><pubDate>Sun, 24 Nov 2002 23:11:24 -0000</pubDate><guid>https://sourceforge.net2112743f4a6cb9d1acb0d0abee0c69f143a07723</guid></item><item><title>0.1-8</title><link>https://sourceforge.net/p/dcprod/news/2002/10/01-8/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;I released 0.1-8. I think I've finally found out why the uploads tended to block. I never even considered that send() could differ form write() in that it blocks until _all_ bytes are written...&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Fredrik Tolf</dc:creator><pubDate>Tue, 15 Oct 2002 00:46:25 -0000</pubDate><guid>https://sourceforge.net22fdd4dbd8237b26829281449d656781d94d4703</guid></item><item><title>0.1-7 released!</title><link>https://sourceforge.net/p/dcprod/news/2002/10/01-7-released/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;After a month of debugging, I believe that I have finally found the cause of the constant segfaults.&lt;br /&gt;
After using valgrind, it seemed they were due to that commands issued by a closing hub remained in the command queue, and were executed with an invalid interface reference when the hub interface was closed. I have not yet done any exhaustive testing, but it has made it through a situation that made it crash almost every time before, namely to be able to connect to a large number of hubs in sequence.&lt;br /&gt;
The problem was fixed simply by adding mutexes to the interfaces and deleting commands from the command queue when the interface they were associated with closes.&lt;br /&gt;
It took some pretty long time, though. I just hope it was worth it.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Fredrik Tolf</dc:creator><pubDate>Sun, 13 Oct 2002 13:57:15 -0000</pubDate><guid>https://sourceforge.netc25bc85174c77042540be5bc592830aacbcf3d79</guid></item><item><title>Kicking</title><link>https://sourceforge.net/p/dcprod/news/2002/10/kicking/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;Just wanted to tell everyone that today I got kicked from my first hub for not having the file list available. The bastards!&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Fredrik Tolf</dc:creator><pubDate>Sun, 13 Oct 2002 02:43:01 -0000</pubDate><guid>https://sourceforge.net707aacdfb82d13785390a355e75d6e30c7cc3dc2</guid></item><item><title>Documentation finished</title><link>https://sourceforge.net/p/dcprod/news/2002/09/documentation-finished/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;I finally took the time to write manpages for dcprod. I have added them to release 0.1-6 along with some extra bugfixes. I finally saw what I had made that could just delete transfers in the middle of the file.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Fredrik Tolf</dc:creator><pubDate>Sun, 01 Sep 2002 16:08:16 -0000</pubDate><guid>https://sourceforge.net48eed46c79456c2a8148c4d5cdaf2d1edc66c049</guid></item></channel></rss>