Language:
switch to room list switch to menu My folders
Go to page: First ... 23 24 25 26 [27] 28 29 30 31 ... Last
[#] Thu Apr 09 2009 16:42:03 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

as mentioned, threadding doesn't bite it. its single task single thread with select who's the king. and all the rest is primarily bit-moving.

apache is a dinosaur. its time to move on.



[#] Thu Apr 09 2009 16:43:52 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

hm... and... wasn't php incompatible with threadding or s.th. like that? there was a reason why prefork isn't dead yet.

 



[#] Thu Apr 09 2009 16:46:26 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


php works with threading. mod_perl is where you run into the need for prefork. anyway, your "single task single thread" comment doesn't make sense

[#] Fri Apr 10 2009 05:43:47 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

have a look at

http://nginx.net/

one task, no additional threads afaik.



[#] Fri Apr 10 2009 07:16:36 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

as mentioned, threadding doesn't bite it. its single task single thread
with
select who's the king. and all the rest is primarily bit-moving.

Perhaps, but not every application lends itself to being written as a state machine. Also, a single thread of execution can't take advantage of multiple CPU's (and with multicore chips now becoming the norm, practically everyone has multiple CPU's).

That having been said, though, the model of having a pool of worker threads running in a "find it, bind it, grind it" loop is definitely a good model for network service applications that need to scale up.

[#] Fri Apr 10 2009 13:50:55 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Apr 10 2009 5:43am from dothebart @uncnsrd
have a look at

http://nginx.net/

one task, no additional threads afaik.


oh, I see what you're saying.

it's wrong. Threads scale better to anything that has actual logic involved.



The purpose of a web server is no longer to just serve static flat files. That's obsolete.

[#] Fri Apr 10 2009 14:18:11 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

it's wrong. Threads scale better to anything that has actual logic
involved.

The problem I have with threads being the be all and end all is that you end up locking resources that you wouldn't have to if you just made a copy (oh, say in another process) yes, you can do this with threads too, but it's more work, just like locking.
Don't get me wrong, I loved threads when I first learned of them, and they are neat and cool and wonderful, but when it comes to massive scaling, it's not the first thing I think of as a good idea.
If nothing else, god forbid there's a bug and somebody crashes your thread EVERYTHING comes down. It's just got too many downsides.

[#] Fri Apr 10 2009 14:43:57 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


I'm fond of asynchronous i/o in place of threads.

Threads require a tremendous amount of mental work for even the most trivial things (at least, it seems that way). Async I/O is simpler, by far, to grasp, and actually can make your code look a lot neater when you do it well.

But, sometimes, you just have to resort to using threads. Threads exist for a good reason... it's just kind of a bitch to manage.

[#] Fri Apr 10 2009 17:45:08 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Fr Apr 10 2009 13:50:55 EDT von LoanShark <>
Apr 10 2009 5:43am from dothebart @uncnsrd
have a look at

http://nginx.net/

one task, no additional threads afaik.


oh, I see what you're saying.

it's wrong. Threads scale better to anything that has actual logic involved.


The purpose of a web server is no longer to just serve static flat files. That's obsolete.

though these flat files make up a relative huge part. And it makes sense to have the frontend being organized so it can do this.

The actual application is served via http proxy / fastcgi / whatever you name it.

there you may have threads / tasks / and so on. to the webserver itself its just another resource it accesses defined by another rule.

So, you see:

webserver -> bitblaster

Servletengine -> applicationlogic



[#] Mon Apr 20 2009 19:41:19 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

heh, you guys run into this one yet?
recent versions of g++ now throw a warning for this:
char *s = "hi from stu.";

What warning you ask?

why deprecated conversion from string constant to char *.
That's right folks, "hi from stu" is a const char pointer, not a char *.
Just when you thought you'd gotten away from const in favor of worse things.
Must be an anniversary or something.,

[#] Mon Apr 20 2009 20:22:26 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Sadly, that actually makes sense to me.

Too often, I've seen programmers try to write to the constant string initiated that way.  It can also lead to some really weird compiler problems as you migrate to other compilers (I've heard of one situation where it took developers a month or so to work out why their problem occured with one compiler but not another... it had something to do with marking the memory as read-only when using string literals).

Still, I can see the frustration.  Dealing with const can be a pain sometimes.



[#] Mon Apr 20 2009 21:17:01 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I agree puristically, it is a const char *.
but fuck, it's been this way for THIRTY YEARS, you have to break every piece of software every written, now? Make a fucking hack of it just this once.


[#] Mon Apr 20 2009 21:17:34 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

And it is read only memory, anybody who does strcpy("hi from marvin", "hi from stu"); deserves what they get.

[#] Mon Apr 20 2009 22:36:31 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

That's right folks, "hi from stu" is a const char pointer, not a char


This warning has been in existence for a long time, not just in g++ also in gcc. You can turn it on/off with -Wconst-char / -Wno-const-char. It's turned on by -Wall or -W... maybe the defaults changed recently and I don't know about it.

[#] Mon Apr 20 2009 22:38:10 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Apr 20 2009 9:17pm from Ford II @uncnsrd
I agree puristically, it is a const char *.
but fuck, it's been this way for THIRTY YEARS, you have to break
every piece of software every written, now? Make a fucking hack of it

just this once.




Yes and no. Turning off -fwritable-strings, or whatever they call it, allows the compiler to emit read-only data sections for all of your strings, which is a nice COW (copy-on-write) optimization.


It's good practice to assume that character constants can't be modified.

[#] Mon Apr 20 2009 23:22:46 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

And I think the compiler should be more than happy to make that executive decision. Hell, if you do things like "string1" "string2" the compiler has to concatenate them into a new constant string anyway.
Doesn't the c spec even say something about them being read only strings? Ahhh, it's just another little ism of life in the future, why do I let these little things get to me.


[#] Tue Apr 21 2009 05:54:43 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

sun CC has been doing this for years now.

GCC switched that with the rise of 4.3

and, yes, they're const strings. You shouldn't free them, you shouldn't write on them, and the compiler plus runtime should be able to detect.

Having an error occur during compile time is allways the better method then having your program crash when its out in the field.



[#] Tue Apr 21 2009 06:48:27 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Well, another way of seeing it is that this exposes a lurking error in your code.

Sometimes, this particular error manifests itself in relatively hidden ways.

Say:

extern void some_fn( char* arg );
void some_other_fn()
{
   char* string_literal = "hi there, folks.";
   some_fn( string_literal );
}

To flag this as an error, you have to pick it up at the assignment.



[#] Tue Apr 21 2009 08:29:48 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Having an error occur during compile time is allways the better method then

having your program crash when its out in the field.

aggreed, but having your program compile after a compiler upgrade should have some value to, and again, I'm all for purist perfection, but in some cases it's not the best answer.
How many times in this world have you been forced to pay money to fix something that isn't broken because you're forced to upgrade because some service contract is running out, when things were just perfectly fine otherwise.

[#] Tue Apr 21 2009 08:32:20 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

To flag this as an error, you have to pick it up at the assignment.

Yes, which brings us believe it or not to the object oriented problem.
the only reason that's a problem is because the caller has to know what some_fn does. If some_fn doesn't in fact do anything but read the string passed to it, there is no problem. the caller would have to know not to pass a static string to it, if it wasn't.
Which is why knowing what your functions do and how they work is terribly important.
Which is why the holy grail of encapsulation only works for pointy haired bosses and not programmers.

Go to page: First ... 23 24 25 26 [27] 28 29 30 31 ... Last