in reply to Re: Re: To Fork for Not to Fork
in thread To Fork for Not to Fork

The use of $|++ is not useless. I can agree there is no need for it to appear in my client code, but there is a good reason for it to appear in the server code.

From time to time, I saw posts complaining their codes are not working simply because of the confusion caused by not-flushed debug infos, which can be easily fixed by setting $|. It is a better practice in multi-threading programming ,to turn on autoflush regardless, unless it is forbidden by the nature of your application. Instead of saying it is useless, I see it as a better style.

I didn't notice the original post is reading from STDIN, instead of the client socket. That's my mistake, but it is understandable, as that doesn't make sense there. I think that's just a simple mistake, and the original author's purpose is to read from the client. However as I pointed out in my original post, his structure is wrong, even changing it to read from client, he will still stuck communicating with the first client, and not going back to accept() until the first client ended.

BTW, next time there is no need to tell me about the down vote. I may think about the reason for getting down voted, but not interested in knowing who did it. Please keep it for your privacy.

As for the technical side, I am a strong promoter for threads, and that was where I was getting. I see it much more important to get the direction correct, than anything else.

Replies are listed 'Best First'.
Re: Re: Re: Re: To Fork for Not to Fork
by tilly (Archbishop) on Nov 11, 2003 at 00:55 UTC
    For my information, can you explain what you consider good about threads?

    My overall opinion is still pretty much what I said a long time ago at Threads vs Forking (Java vs Perl). Switching threads is faster, debugging multi-threaded programs is much harder, and as the tangential discussion at the end points out, forking scales better if extreme scalability is needed. (The fact that high-end boxes now tend to jump hoops to avoid scheduling different threads on different CPUs underscores the fundamental scalability issue.)

    I have updated some parts of my opinion though. Perl 5.8's threading model makes threading usable in Perl for definitions of usable that include slow and memory bloated.

    Therefore I would personally avoid going multi-threaded unless I was writing code to run on a platform that strongly pushes you that way (Java and Windows both come to mind), or unless I was writing an application where interactive latency was significantly more important than throughput (eg a user-facing desktop program).

    However I haven't done much with threading (the above shows why I tend to choose not to) and I like to update my information from time to time. (And yes, I do regularly wind up changing my opinion as well...) So I wouldn't mind feedback on why you think that threads are the right direction for people to take in more situations.