A programming convention

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

A programming convention

Vlad Dumitrescu-4
I think it would be very helpful if such a convention would be established
and used (nonetheless in OTP)!

>   maybe() ::= {value, X} | none
>For situations where I know that something might not have a value and I'll
>make no attempt at handling the unexpected behaviour.

I'm not sure if it is really an 'unexpected' behaviour... after all, both
the function's implementor and user need to plan for it happening.

>         might() ::= {ok, Value} | {error, Why}
>For situations where I know that something might not work and I may wish
>to handle the unexpected behaviour. Example handling {error, enofile} in
>file:open
>
>must() ::= Value | EXIT(Why)
>I require the expected behaviour and want to crash if I cannot continue.

I would like to add another case that is a combination (with an ugly name)
    maybe_or_might() ::= {value, X} | none| {error, Why}
because (taking the example of "lookup") a key search might or might not
return any value, while during the call the dictionary server might crash
(or Mnesia gets into an incosistent state, or something).

>I think the *important* thing is that *everybody* uses the standard types
>and NOT their own variants.

I agree completely.

regards,
Vlad

_________________________________________________________________
MSN Foto ?r det enklaste s?ttet att dela eller skaffa papperskopior av dina
foton: http://photos.msn.com/support/worldwide.aspx



Reply | Threaded
Open this post in threaded view
|

Changing Code

Richard Carlsson-4

The dynamic code update semantics of Erlang is a nice feature when
you're in prototyping mode, but for production code, the fact that any
inter-module ("remote") call can be redirected at any time to a new
version of the called module is a big obstacle for the compiler when it
comes to generating efficient code. To be able to maybe do something
about this, we'd like to know more about how code update is actually
being used (and handled) in real Erlang systems of today. Things we
would like to hear about include:

        - Is it necessary to be able to exchange any single module?
          (E.g., if your application consists of a number of modules,
           do you always replace all these modules anyway?)

        - Could code migration be limited to specific functions, or
          is it necessary to be able to switch to a new version at all
          "remote" calls. (E.g., one could imagine a new declaration
          for specifying only certain functions as code update points.)

        - Do you always use the OTP release handler or similar to
          do code updates, or do you do it by hand, or with your own
          in-house tools, etc? Do you find it simple as it is today,
          or is code update so difficult that you try to avoid it?

        - How much of a problem are circular module dependencies in
          practice?

        - Is the flexibility of being able to change any module at any
          time (even in production code) worth more to you than the
          speed of the code?

        - When you make a (remote) call that is expected to switch
          to new code whenever it has been loaded, could you guarantee
          that the call stack is empty at that point, i.e., you will
          not return to the old code, nor to the code that called it?
          (If so, the code purging stage would not have to scan the
          stacks of processes to find out if they must be killed.)
          This pretty much equals saying that code change always starts
          a fresh process, but keeps the old Pid.

        - Anything else that you find important.

Thanks,

        /Richard & the HiPE posse



Richard Carlsson (richardc)   (This space intentionally left blank.)
E-mail: Richard.Carlsson WWW: http://www.csd.uu.se/~richardc/
 "Having users is like optimization: the wise course is to delay it."
   -- Paul Graham



Reply | Threaded
Open this post in threaded view
|

Changing Code

Matthias Lang-2
Hi,

For what it's worth, our little SS7 box has a fair bit of Erlang in it and
we have never used hot code loading to upgrade live systems.

Richard Carlsson writes:

 > The dynamic code update semantics of Erlang is a nice feature when
 > you're in prototyping mode, but for production code, the fact that any

The difference between production and prototyping isn't always
clearcut. It may take a long time during testing to get a system to
behave strangely (e.g. performance degradation after a week of load
testing). It's nice to run that sort of testing on code intended for
production, but convenient to then load in instrumented code without
having to restart the system and wait another week for the problem to
show.

That goes double if the misbehaving system is in a customer's test lab.

 > - Is it necessary to be able to exchange any single module?
 >  (E.g., if your application consists of a number of modules,
 >   do you always replace all these modules anyway?)

Doesn't replacing all but one module in a system with the same code as
is currently running amount to the same behaviour from the user's
point of view? I guess it requires more confidence in your CVS setup
if those 'identical' files are recompiled.

 > - Could code migration be limited to specific functions, or
 >  is it necessary to be able to switch to a new version at all
 >  "remote" calls. (E.g., one could imagine a new declaration
 >  for specifying only certain functions as code update points.)

The most common code load for me is loading new code for a
gen_server. I usually don't care exactly when the switch happens, as
long as (a) it happens within a few seconds and (b) I know that it happened.

 > - Do you always use the OTP release handler or similar to
 >  do code updates, or do you do it by hand, or with your own
 >  in-house tools, etc? Do you find it simple as it is today,
 >  or is code update so difficult that you try to avoid it?

I do code update by hand.

 > - How much of a problem are circular module dependencies in
 >  practice?

Never bumped into this problem.

 > - Is the flexibility of being able to change any module at any
 >  time (even in production code) worth more to you than the
 >  speed of the code?

All the bottleneck code in our system is written in C, either as a
device driver or a port program, so for that code the "speed is more
important than hot code loading" decision has already been taken. In
most of the remaining Erlang code, I'd be loathe to give up hot code
loading.

If there was a compiler switch for "faster standard libraries but no
hot code loading for them", I'd enable it.

Matthias


Reply | Threaded
Open this post in threaded view
|

Changing Code

Gerd Flaig-2
In reply to this post by Richard Carlsson-4
Richard Carlsson <richardc> writes:

> - Is it necessary to be able to exchange any single module?
>  (E.g., if your application consists of a number of modules,
>   do you always replace all these modules anyway?)

I use this feature frequently while in development mode. Sometimes
even on production nodes to hot-fix bugs.

> - Could code migration be limited to specific functions, or
>  is it necessary to be able to switch to a new version at all
>  "remote" calls. (E.g., one could imagine a new declaration
>  for specifying only certain functions as code update points.)

As I use generic behaviours almost exclusively, this has not been an
issue anyway.

> - Do you always use the OTP release handler or similar to
>  do code updates, or do you do it by hand, or with your own
>  in-house tools, etc? Do you find it simple as it is today,
>  or is code update so difficult that you try to avoid it?

We wrap our releases in Debian packages. I would like to have tight
integration between the OTP release handler and the Debian package
system. Most of the time, though, we just shut down the node while
upgrading.

> - How much of a problem are circular module dependencies in
>  practice?

Not much of a problem for me, yet.

> - Is the flexibility of being able to change any module at any
>  time (even in production code) worth more to you than the
>  speed of the code?

The speed of the code has not been an issue until now.

> - When you make a (remote) call that is expected to switch
>  to new code whenever it has been loaded, could you guarantee
>  that the call stack is empty at that point, i.e., you will
>  not return to the old code, nor to the code that called it?
>  (If so, the code purging stage would not have to scan the
>  stacks of processes to find out if they must be killed.)
>  This pretty much equals saying that code change always starts
>  a fresh process, but keeps the old Pid.

I'm not sure. Would it be enough to only make qualified
intra-module-calls when they're tail-calls?

      Goodbyte, Gerd.
--
Gerd Flaig                     Technik                gerd
Bei Schlund + Partner AG       Erbprinzenstr. 4-12  D-76133 Karlsruhe
 Physics is like sex: sure, it may give some practical results,
 but that's not why we do it. -- Richard Feynman


Reply | Threaded
Open this post in threaded view
|

Changing Code

Thomas Lindgren-3
In reply to this post by Richard Carlsson-4

Richard Carlsson wrote:
> - Is it necessary to be able to exchange any single module?
>  (E.g., if your application consists of a number of modules,
>   do you always replace all these modules anyway?)

Installing simple patches by loading new modules in a live system has been
used at both Bluetail and Cellpoint. (This can also be used to impress
customers :-)

> - Could code migration be limited to specific functions, or
>  is it necessary to be able to switch to a new version at all
>  "remote" calls. (E.g., one could imagine a new declaration
>  for specifying only certain functions as code update points.)

Don't know.

> - Do you always use the OTP release handler or similar to
>  do code updates, or do you do it by hand, or with your own
>  in-house tools, etc? Do you find it simple as it is today,
>  or is code update so difficult that you try to avoid it?

Bluetail used release handlers IIRC, Cellpoint does not.

> - How much of a problem are circular module dependencies in
>  practice?

I believe OTP is full of circular module dependences. (Since Erlang handles
this without complaint, most people probably don't, however, consider it a
problem :-)

> - Is the flexibility of being able to change any module at any
>  time (even in production code) worth more to you than the
>  speed of the code?

Yes.

> - When you make a (remote) call that is expected to switch
>  to new code whenever it has been loaded, could you guarantee
>  that the call stack is empty at that point, i.e., you will
>  not return to the old code, nor to the code that called it?
>  (If so, the code purging stage would not have to scan the
>  stacks of processes to find out if they must be killed.)
>  This pretty much equals saying that code change always starts
>  a fresh process, but keeps the old Pid.

No.

Best,
                                        Thomas