[Dillo-dev]Re: Is IO.txt outdated?
It says dillo uses threads for DNS querying and reading local files, and signal driven I/O for TCP connections. When the socket gets ready for transmission, the data is sent using g_io_channel_write. But I can't not find the place where g_io_channel_write is invoked in the code.
Yes, once upon a time it used g_io_channel_write, but not anymore. I'll update this doc ASAP and let you know when its ready.
In previous posts I see "When using threads and mutexes (pthreads), thread scheduling is done by a third thread or by the kernel (depends upon the implementation), and it is preemptive. Now, the address space may be shared, so the need for mutexes arise, and because of both reasons, performance is degraded. Using a pseudo-thread (CCC thread), doesn't require scheduling by an external process or by the kernel. All is done in the same process, but there's no preemption." But I do find a thread is spawned in "a_IO_write_chunk()". Would you please tell me the reason?
Otherwise it wouldn't generate IO signals.
What does pseudo-thread mean?
A non-preemptive thread as those handled by CCC.
I don't think it is really parallel. If there are several connections at the same time, one must wait until another one completes data transfer. assume such a case: one connection is responsible for downloading a big image, and other connections are going to download small images. The former one's G_IO_IN event is triggered first and it begins to download the big image. It will take long for it to complete downloading and other connections have to wait. It's unfair for them though they will cost much less time. I don't know whether I'm right. Must other connections wait until one completes or error occurs?
Is such thread spawned in "a_IO_write_chunk()" pseudo-thread?
No that one is a POSIX thread (or pthread at least ;).
-- Cheers Jorge.-
Folks, Some elements of the latest CVS patch breaks older c compilers... Personally I like the "declare when you need it" behavior, but gcc2.95 doesn't. The fix is almost trivial: %%%%%%%%%% diff -pru dillo_c99/src/interface.c dillo/src/interface.c --- dillo_c99/src/interface.c Fri Aug 13 12:25:02 2004 +++ dillo/src/interface.c Fri Aug 13 12:17:50 2004 @@ -1329,6 +1329,7 @@ static gchar *Interface_make_search_url( { gchar *keys = a_Url_encode_hex_str(str), *c = prefs.search_url; GString *newstr = g_string_sized_new(strlen(c)+strlen(keys)); + gchar *search_url; for (; *c; c++) if (*c == '%') @@ -1347,7 +1348,7 @@ static gchar *Interface_make_search_url( g_free(keys); - gchar *search_url = newstr->str; + search_url = newstr->str; g_string_free(newstr, FALSE); return search_url; } diff -pru dillo_c99/src/url.c dillo/src/url.c --- dillo_c99/src/url.c Fri Aug 13 12:25:02 2004 +++ dillo/src/url.c Fri Aug 13 12:22:07 2004 @@ -540,13 +540,12 @@ gchar *a_Url_decode_hex_str(const gchar */ gchar *a_Url_encode_hex_str(const gchar *str) { - if (!str) - return NULL; - static const char *verbatim = "-_.*"; static const char *hex = "0123456789ABCDEF"; - char *newstr = g_new(char, 6*strlen(str)+1), *c; + + if (!str) + return NULL; for (c = newstr; *str; str++) if ((isalnum(*str) && !(*str & 0x80)) || strchr(verbatim, *str)) %%%%%%%%%% -- -- David McKee -- dmckee@jlab.org -- (757) 269-7492 (Office)
Folks, I've been thinking a little about my comment the other day to the effect that I prefer more contrast in list views than the new file:// dpi's table mode provided. I wondered if that might be a reasonable candidate for a configurable preference. It's not clear that it is, but it got me thinking about handling preferences in dpi. I suggest that we don't want every dpi implementing it's own preferences scheme. So dpid should handle reading in any preferences for dpis, and pass them to the plugin. The simplest method would be to set environment variables in the new processes execution environment. If we are willing to tolerate having preferences read in only at startup (as with the main program right now) that is the whole of the problem. For reading user preferences from disk we can presumably use the same code that is current employed to get the dillo preferences... Any thoughts? Cheers, -- -- David McKee -- dmckee@jlab.org -- (757) 269-7492 (Office)
participants (2)
-
Calvin Yu -
David McKee