(no subject)
Nov. 10th, 2000 11:49 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
pphaneufI am trying to see how one is supposed to bootstrap himself with this certification system. I think it is a very cool idea, but it's hard "getting a voice".
I would have liked being able to comment on the Autobook article today, to say that RecursiveMakeConsideredHarmful, seeing how Automake encourages recursive makefiles.
Nice, the diary being Wiki-enabled! PierrePhaneuf loves Wiki!
Thought about threads: as I wrote about on my home page, I dislike threads and their pervasive overuse in modern software (both closed and open source). One of the big problem where I often have to resolve to threads (or fork) is when one of your inputs is time.
Most other forms of inputs can be turned into a file descriptor that can be fed to some select()-based main loop (like Xt or the one in glib), like signal handlers writing a byte into a pipe. A file descriptor is very handy, and can easily brige arbitrary libraries. For example, you can get the ConnectionNumber() of an Xlib display, and register it with glib main loop.
Time can be handled in such loops (with the select() timeout), and libraries like glib and Xt have hooks to register time-based events, but the problem is that a library that want to register a time event has to know the main loop library itself.
This problem came up trying to think of a way to do asynchronous DNS nicely without resorting to threads. For (the rarely used) TCP DNS requests, you can just select() that, but for the (much more common) UDP requests, you might never get anything, and the library has to timeout at some point.
I could implement that async DNS library as a component of my main loop system, but that is ugly and has no doing there. I want someone to be able to use my library with Xt, glib and other main loop libraries!
It would be nice if timers could exist as file descriptors. I think they do on Win32 (as handles usable in WaitForMultipleObjects or somesuch).
Yes, I know of SIGALRM, but you can only have one of these at once. I could spawn a thread or fork something to do this, but I could as well do the whole lookup in there.
Oh well. That's life I guess!
P.S.: dank has good ideas about threads and select() and all of this. Kudos for his C10K web page.
I would have liked being able to comment on the Autobook article today, to say that RecursiveMakeConsideredHarmful, seeing how Automake encourages recursive makefiles.
Nice, the diary being Wiki-enabled! PierrePhaneuf loves Wiki!
:-)
Thought about threads: as I wrote about on my home page, I dislike threads and their pervasive overuse in modern software (both closed and open source). One of the big problem where I often have to resolve to threads (or fork) is when one of your inputs is time.
Most other forms of inputs can be turned into a file descriptor that can be fed to some select()-based main loop (like Xt or the one in glib), like signal handlers writing a byte into a pipe. A file descriptor is very handy, and can easily brige arbitrary libraries. For example, you can get the ConnectionNumber() of an Xlib display, and register it with glib main loop.
Time can be handled in such loops (with the select() timeout), and libraries like glib and Xt have hooks to register time-based events, but the problem is that a library that want to register a time event has to know the main loop library itself.
This problem came up trying to think of a way to do asynchronous DNS nicely without resorting to threads. For (the rarely used) TCP DNS requests, you can just select() that, but for the (much more common) UDP requests, you might never get anything, and the library has to timeout at some point.
I could implement that async DNS library as a component of my main loop system, but that is ugly and has no doing there. I want someone to be able to use my library with Xt, glib and other main loop libraries!
It would be nice if timers could exist as file descriptors. I think they do on Win32 (as handles usable in WaitForMultipleObjects or somesuch).
Yes, I know of SIGALRM, but you can only have one of these at once. I could spawn a thread or fork something to do this, but I could as well do the whole lookup in there.
Oh well. That's life I guess!
P.S.: dank has good ideas about threads and select() and all of this. Kudos for his C10K web page.
